From:           IAB/IESG
For comment to: ITU-T Q7/SG13
In response to: Liaison TD 324 from ITU-T Q.7/13
Title:          Regarding ITU-T Q.7/13 work related to IPv6 NGN


The IESG and IAB thank you for the opportunity, through the liaison
received from Q.7/13, to review and respond to the draft
recommendations on IPv6, ITU-T Y.ipv6-vmh, ITU-T Y.ipv6split and ITU-T
Y.ipv6migration.  As always, we welcome the opportunity for
interaction and collaboration between the IETF and the ITU-T.

The IETF has been working on various mechanisms related to some of the
topics addressed in ITU-T Y.ipv6-vmh, ITU-T Y.ipv6split and ITU-T
Y.ipv6migration.  The IETF looks forward to continued collaboration
and constructive interaction between the IETU-T and the IETF in these
areas.  We recommend and encourage the ITU-T to identify, considering
the charters of the relevant IETF working groups, where the boundary
lies between IETF work items and ITU-T work items and engage the IETF
in review of that division.

In ITU-T Y.ipv6-vmh, Q.7/13 takes a different approach to the problem
of multi-homing and multiple interfaces ITU-T than the usual IETF
practice.  Multi-homing is a problem that can be solved at several
different layers of the protocol stack, so a vertical design that
examines different strategies is a good approach. 

The IETF mif (Multiple InterFaces) working group is working on
related problems.  From the working charter, the goal of the mif
working group is "to describe the issues of attaching to multiple
networks on hosts and document existing practice."  The working group
is publishing two documents analyzing the problem space:

draft-ietf-mif-current-practices-02
         Current Practices for Multiple Interface Hosts
draft-ietf-mif-problem-statement-05
         Multiple Interfaces Problem Statement

The mif working group is currently rechartering and will begin to
develop solutions to some of the problems identified in its published
analysis.

The mptcp (MultiPath TCP) working group is addressing the problem of
multi-homing at the transport layer.  One aspect of note in MPTCP is
that just knowing interface characteristics isn't enough, a transport
layer entity needs to know end-to-end goodput.  In MPTCP there are
three criteria: goodput, cost, and policy.

The IAB and IESG would welcome continued interaction with Q.7/13
regarding Y.ipv6-vmh.  Because of the different styles of analysis in
ITU-T Q.7/13 and IETF working groups, we recommend focusing discussion
in IETF working groups on the layer of interest in the working group;
for example, focusing on the internet layer in the mif working group.

The draft Recommendation ITU-T Y.ipv6split addresses the concept of
identifier/locator separation in IPv6, which was also the subject of a
recent liaison exchange regarding Y.FAid-loc-split.  Much of the
discussion in that liaison can be applied specifically to IPv6.  We
recommend the IAB/IETF liaison to Q5/SG13 as a source of information
about concepts and protocols under development in the IETF, and we
encourage Q5/SG13 to engage the IETF in further discussion of the IPv6
identifier/locator separation framework.

In response to your document ITU-T Y.ipv6migration, "Roadmap for IPv6
migration from NGN operators' perspectives", we appreciate your
analysis of the phases in a transition, operational scenarios to be
supported and characterization of transition techniques.  Several IETF
working groups, as detailed below, have produced some complementary
documents.

The IETF v6ops working group, which from its charter "provides
operational guidance on how to deploy IPv6 into existing IPv4-only
networks [and] new network installations," has produced a series of
RFCs that describe transition scenarios that describe deployment and
transition scenarios:

RFC 3750 Unmanaged Networks IPv6 Transition Scenarios
RFC 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged
         Networks
RFC 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks
RFC 4057 IPv6 Enterprise Network Scenarios
RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers
RFC 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks
RFC 4942 IPv6 Transition/Co-existence Security Considerations

The IETF behave working group, which "documents best current practices
to enable NATs to function in as deterministic a fashion as possible,"
has identified a list of scenarios similar to the 6 deployment
scenarios in Y.ipv6migration.  It is in the process of publishing the
following documents:

RFC 4787 Network Address Translation (NAT) Behavioral Requirements for
         Unicast UDP 
RFC 5135 IP Multicast Requirements for a Network Address Translator
         (NAT) and a Network Address Port Translator (NAPT) 
RFC 5382 NAT Behavioral Requirements for TCP
RFC 5508 NAT Behavioral Requirements for ICMP
RFC 5597 Network Address Translation (NAT) Behavioral Requirements for
         the Datagram Congestion Control Protocol 
RFC 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to
         Session Traversal Utilities for NAT (STUN) 
RFC 5780 NAT Behavior Discovery Using Session Traversal Utilities for
         NAT (STUN) 

The IETF softwire working group, developing techniques for tunneling
traffic of one address family over the other address family, is in the
process of publishing the following documents:

draft-ietf-softwire-ipv6-6rd-10.txt 
         IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
draft-ietf-softwire-dual-stack-lite-05
         Dual-Stack Lite Broadband Deployments Following IPv4
         Exhaustion