[ipv6-dir] Fwd: Comments on "IETF / IAB response to ITU Q.9/13 questions on IPv6 development"

[Bob Hinden <[e-mail]>]

Forwarding to the larger list.

Bob

--------------------------

Begin forwarded message:

From: "Bob Hinden" <[e-mail]>
Date: January 6, 2006 3:38:12 PM PST
To: IAB <[e-mail]>
Subject: Comments on "IETF / IAB response to ITU Q.9/13 questions on  
IPv6 development"

Here are my comments on what I think is the current version.

My general comment is that I think this response might be better if  
it focused more the facts by pointing to work in the IETF in each  
topic area instead of what appears to be a commentary on that work.   
I think we may be falling to trap similar to when a three year old  
asks "where do babies come from".  Providing the details of sex is  
not usually what they want to know about.

Once our colleagues in the ITU come up to speed in these areas we  
might have another discussion.

Bob




> IETF / IAB response to ITU Q.9/13 questions on IPv6 development
>
>
>
> Introduction
>
> The IETF thanks the Q.9/13 for their liaison statement (https:// 
> datatracker.ietf.org/documents/LIAISON/file182.pdf)  and interest  
> on IPv6 issues related to NGN.  We have reviewed the liaison  
> statement with the most relevant experts and prepared this response  
> based on those experts' comments.   We have aimed to provide an  
> informative response for your guidance in further collaboration,  
> and  have endeavoured to be clear where works are “in progress”.   
> We also appreciate your understanding that, while this is the  
> collected advice from several experts, it is neither an IAB  
> statement nor an official IETF consensus publication.
>
> Future IPv6development
>
> QoS signaling

I think this should start with something like:

IPv6 uses the same signaling mechanisms as IPv4.  These include  
Integrated Services using RSVP and Differentiated Services.

> RSVP has seen some deployment, but are localized.  There have been  
> scalability issues with some aspects of RSVP and other QoS  
> signaling protocols.  See “Analysis of Existing Quality-of-Service  
> Signaling Protocols” RFC 4094. RSVP supports IPv6.  The major RSVP  
> RFCs are:
>
> l     RSVP Version 1 Applicability - RFC 2208
> l     RSVP Version 1 Message Processing Rules - RFC 2209
> l     RSVP Operation Over IP Tunnels - RFC 2746
> l     RSVP Cryptographic Authentication - RFC 2747
> l     RSVP Refresh Overhead Reduction Extensions - RFC 2961
> l     RSVP Cryptographic Authentication-New Message Type - RFC 3097
> l     Format of the RSVP DCLASS Object - RFC 2996
> l     Specification of the Null Service Type - RFC 2997
> l     A Framework For IntServ Operation Over Diffserv Networks -  
> RFC 2998
> l     RSVP Reservations Aggregation - RFC 3175
>
> The Next Steps in Signaling Working Group has been chartered to  
> work on the next steps for Internet signaling, including QoS  
> signaling.  NSIS has defined a signaling framework, detailed in  
> Next Steps in Signaling (NSIS): Framework (RFC 4080).  This  
> proposes a two-layer architecture consisting of a transport  
> protocol and signaling application.  The transport protocol is GIST  
> (General Internet Signaling Transport) - http://www.ietf.org/ 
> internet-drafts/draft-ietf-nsis-ntlp-08.txt.  GIST supports both  
> IPv4 and IPv6.
>  There is a NSIS Signaling Layer protocol for QoS: NSLP for Quality- 
> of-Service signaling - http://www.ietf.org/internet-drafts/draft- 
> ietf-nsis-qos-nslp-08.txt.  NSIS supports signaling for multiple  
> QoS models, and has defined a basic template so that different QoS  
> mechanisms can be supported: QoS-NSLP QSPEC Template - http:// 
> www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt.  Y.1541- 
> QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes --  
> is currently being developed, http://www.ietf.org/internet-drafts/ 
> draft-ietf-nsis-y1541-qosm-00.txt, for example. GIST has completed  
> Working Group Last Call is awaiting a document revision.  “The NSIS  
> Signaling Layer protocol for QoS” & “QoS-NSLP QSPEC Template”  
> drafts should shortly be ready for Working Group Last Call. There  
> is on-going work on IPv6 transition issues for SIP, see: “IPv6  
> Transition in the Session Initiation Protocol (SIP)” - http:// 
> www.ietf.org/internet-drafts/draft-ietf-sipping-v6-transition-01.txt.
>
> QoS signaling interworking, IPv4<->IPv6

Suggest adding:

The IETF has not planned on direct translation between IPv4 and  
IPv6.  As a consequence there hasn't not been any work on mapping  
IPv6 and IPv4 QOS.  Generally the IETF focuses on Internetworking,  
not Interworking.

> RFC 4080 defines a layered, modular architecture to support  
> different network deployments.  Since GIST works in a hop-by-hop  
> manner, it is possible to chain transport connections and between  
> IPv4 and IPv6 networks, without significant impact to the QoS  
> Signaling application.  There is on-going work to study how this  
> signaling will work over different tunneling mechanisms, such as IP  
> transition mechanisms.  See: “NSIS Operation Over IP Tunnels” -  
> http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01.txt
>
> IPv4 / IPv6 interaction and transition

Suggest adding references to the IPv6 transition working group and  
citing RFC's developed there.  A link the the charter page would do  
that.

> The interaction of IPv4 and IPv6 is closely related to the IETF  
> work on transition mechanisms. The normal IETF approach is to use  
> one, or the other as the transport mechanism for bridging native  
> connectivity islands of the other. This is done by of a number of  
> encapsulation or tunneling technologies defined by the IETF. The  
> main exception is the use of application layer gateways, or ALG.  
> These works as proxies, handling translation of protocols  
> transported over one IP version to be transported by another. These  
> ALGs work on a per protocol, and while deployed and in use, are not  
> common.
>
> IPv6 flow label


> The IPv6 flow label is described in RFC 3697. In IPv4, a flow of IP  
> packets are traditionally defined as

s/describe/defined/

> the tuple (source IP, destination IP, source port, destination  
> port, transport protocol type). For a number or reasons, this is  
> not a viable approach in IPv6, among others as the protocol type is  
> encoded
> in the nested next-header value, which would require a “deep packet  
> inspection” in worst case. Some of the values might also not be  
> available in a packet due to fragmentation or encryption. Therefore  
> in IPv6, a flow is identified by the source address, destination  
> address and the flow-label field in the IPv6 packet header.

Suggest replacing the previous sentence with:

"Therefore in IPv6, the flow label field is used to identify flows.   
RFC3697 specifies that an IPv6 flow is identified by the source  
address, destination address, and the flow-label field.  The flow  
label is required to be preserved end-to-end.

>
> The IPv6 flow label identifier is a 20-bit field in the IPv6  
> header. A value of zero indicates that no flow id is set and no  
> assumption on the packets being part of a flow can be made.  
> Further, nodes must not assume that there is a semantic meaning of  
> the flow label field. This has had relevance in several IETF  
> Working groups and related work, where the possibility of using the  
> Flow label field is considered for overloading the semantics for  
> other work. This has most of the time been an artifact of work that  
> would have benefited from a field of its own in the IPv6 header.  
> This has so far been deemed incompatible with the definition of the  
> flow label field.

I don't understand the previous paragraph starting with "had  
relevance in...."

> Last it’s worth noticing that RFC 3697 does not make any  
> assumptions on how flows are processed or used. It also make the  
> assumption that flows will be labeled based on a host decision, but  
> it does not say anything on how these decisions are made or what  
> they are based on, other than noticing that future work could  
> include a flow-label signaling protocol.
>
> There is currently work under way in the IETF that looks at using  
> the flow-label field for its “originally” intended value, such as  
> the work in the NSIS WG.

What does " “originally” intended value" mean?  Does this mean that  
there was some intent other than RFC3697, or does it mean RFC3697?

I think it might be better to just point to RFC 3697 instead of  
trying to summarize and comment on it.

>
> Multihoming with IPv6
>
> Multihoming in IPv6 has been the focus for a lot of work both  
> inside the IETF and in the operational community involved at each  
> of the Regional Internet Registries, the RIRs (AfriNIC, RIPE,  
> APNIC, L ACNIC, and ARIN). Today address blocks of /32 in size are  
> used as the initial allocation standard by the RIRs, unless  
> explicit need for larger blocks in the near future can be proved.  
> Then larger initial allocation blocks have been used in order to  
> preserve aggregation and limit the impact on global routing table  
> growth. The criteria for receiving an initial allocation from the  
> RIRS, commonly used today is, that an organization is a member of a  
> RIR and can present plans for 200 allocations to third parties  
> within two years. For organizations not meeting these criteria, it  
> is assumed that they can get address blocks allocated from their  
> providers that should meet the previous criteria. All along it has  
> been known that end-site organizations might have a need for  
> multiple providers and a seamless transition is use of service  
> between the two. For this reason the IETF early created the multi6  
> working group in the operations area. Multi6 was tasked with  
> defining the operational needs of a multihoming solution. Those are  
> summarized in the RFC 3582, “Goals for IPv6 Site-Multihoming  
> Architectures”. The multi6 working group concluded with an  
> architectural analysis of the available options and their trade- 
> offs. These are described in RFC 4177, “Architectural Approaches to  
> Multi-homing for IPv6”. The conclusion was that the IETF should  
> work on a mechanism that allowed a host with multiple IPv6  
> addresses from multiple providers, to transition the use of source  
> and destination IPs, without breaking transport layer state. This  
> is achieved by the use of what is commonly called the identifier  
> locator split and the insertion of a shim layer between the upper  
> layer protocols and the IP layer. This work is carried out in a new  
> working group called shim6.
>
> In addition to this effort, other technologies in the IETF support  
> some form of multihoming, most notably HIP, which is an  
> experimental protocol with many similarities to shim6, and SCTP.  
> The reason SCTP was not chosen as a generic approach to multihoming  
> was that it assumes SCTP as the transport layer protocol.
>
> Mobility.
>
> The IPv6 mobility model, Mobile Support in IPv6 aka Mobile IPv6,  
> has been adopted from the IPv4 version Mobile IP, with some  
> modifications and extensions.  Especially the security model for  
> route optimisation is different.  Mobile IPv6 is documented in RFC  
> 3775 and RFC 3776, with an optional extension in RFC 4283.  RFC  
> 4225 explains the rational and design behind the route optimisation  
> security model, and its limitations.
>
> Basic support for Mobile subnetworks is defined in RFC 3963.  The  
> approach taken is an extension to Mobile IPv6, and does not  
> necessarily scale to all network environments.  An alternative  
> approach, based on creative application of the routing protocol  
> standards, is implemented in the commercial Boeing Connexion service.

I didn't think the Boeing service was supporting IPv6?  I thought  
their approach is IP version independent.  Might be good to say that  
if it is going to be mentioned.

> The IETF is currently considering extensions and, in the longer  
> term, potential alternatives, to Mobile IPv6.  Issues being  
> addressed include mobility between IPv4 and IPv6, combined mobility  
> and multi-homing, security issues related to mobility, and deeper  
> architectural problems related to the possible need of revising the  
> architecture along the so called identifier/locator split suggestion.
>
> Extensions, optimisations, and options to Mobile IPv6 are being  
> studied in the MIP6, MIPSHOP, and MONAMI6 working groups.  The NEMO  
> working group continues to work on subnetwork mobility.
>
> Potential alternatives to Mobile IPv6, currently applicable at most  
> in certain restricted environments, include Mobility support for  
> IPsec, being studied at the MOBIKE WG, proposed extensions for  
> transport layer mobility (including extensions to SCTP and DCCP),  
> and proposed extensions to IPv6 multi-homing (SHIM6)  
> functionality.  Along even more research-oriented lines, the HIP  
> working and research groups are studying combined mobility and  
> multi-homing in an environment where the so called identifier/ 
> locator split is implemented in a certain way.  However, at this  
> time it is not clear whether the HIP approach is viable in the  
> first place or not, due to problems related to distributed  
> identifier/locator mapping and the required infrastructure.
>
> MPLS and IPv6.
>
> The relationship between MPLS and IPv6 is basically orthogonal,  
> i.e. MPLS work equally well with IPv6 and IPv4. Some IPv6 specific  
> issues are addressed in RFC3032 “MPLS Label Stack Encoding”.  This  
> has to do with encapsulating IPv6 in MPLS in specific cases, e.g.  
> when an IPv6 packet is too large or an explicit NULL encapsulation  
> is needed.
>
> The LDP specification (RFC3036) and the RSVP-TE specification  
> (RFC3209) describe how to encode IPv6 specific information when  
> establishing signaling sessions and setting up LSPs.
>
> If ITU-T SG13 is aware of other MPLS related IPv6 issues we are  
> prepared to participate in resolving those, please send them in  
> liaison statements to the MPLS Working group and the IPv6  
> directorate jointly.
>
> We are not aware of MPLS implementations for IPv6 networks, but  
> will solicit this information and notify the ITU-T SG13 of the  
> result when available.
>
>
>  The IETF appreciates the interest of Q.9/13 and the continuing
>   cooperation between ITU and the IETF.  Please let us know if  
> there are
>   further questions concerning IETF technical work, and we would  
> welcome
>   the opportunity to direct your members to appropriate IETF Working
>   Groups to carry out the technical discussion more directly.




_______________________________________________
ipv6-dir mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipv6-dir