RE: IAB last call... Re: [ipv6-dir] Re: Updated document

["Margaret Wasserman" <[e-mail]>]

Hi Thomas,

I like these changes...

I like the approach of sending them some non-controversial information that we hope will help them, while at the same time strongly encouraging them to come back to us with any more specific questions.  I think that is more-or-less what we have been trying to do all along, and I think that Thomas' changes make that more explicit.

Who has the 'pen' at this point?  Kurtis, do you want to take a pass at integrating Thomas' changes?  Or do you want me to do it?

Perhaps I could put a final proposal together today, and we could have a call tomorrow or Wednesday to review it and correct any remaining blocking issues?  I really would like to get this out by thursday, so that it can be considered by ITU.

Thanks,
Margaret 

> -----Original Message-----
> From: Thomas Narten [mailto:[e-mail]] 
> Sent: Monday, January 09, 2006 9:55 AM
> To: Leslie Daigle
> Cc: IAB IAB; [e-mail]; Scott W Brim; Margaret 
> Wasserman; Bradner Scott; [e-mail]; Kurt Erik Lindqvist
> Subject: Re: IAB last call... Re: [ipv6-dir] Re: Updated document 
> 
> Reading some of the comments, I sense there is still some 
> discomfort with the current version. Here's my attempt at 
> slimming it down, i.e., having less "editorialization" and 
> trying to simply point to WGs and existing RFCs. The overall 
> message should be: "there is lots of ongoing work, talk to us 
> about specifics". IMO, the less we say the better, since we 
> don't want any "advice" to be taken as some sort of 
> "recommendation". I'd want more details about a specific 
> question/usage before doing that. Best to just point to the 
> existing work and encourage them to come to the IETF with 
> specific questions. Saying more now is in some sense trying 
> to anticipate their questions, which we probably can't reasonably do.
> 
> > IETF / IAB response to ITU Q.9/13 questions on IPv6 development
> 
> IETF 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 subject-matter experts and have prepared the 
> response.
> > 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.
> 
> The IETF thanks 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 IETF subject-matter experts and 
> prepared the following response.  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 this is not a specific recommendation. It is a general 
> summary of the work the IETF has done and is currently 
> pursuing.  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.
> 
> > Future IPv6development
> > 
> > QoS signaling
> 
> Add:
> 
>     IPv6 uses the same QoS 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:
>     
> RSVP has seen some deployment, but those deployments are localized.
> Some scalability issues with some aspects of RSVP and other 
> QoS signaling protocols have been identified.  See ¡ÈAnalysis 
> of Existing Quality-of-Service Signaling Protocols¡É RFC 4094 
> or more details. RSVP supports IPv6.  The major RSVP RFCs are:
> 
> > 	RSVP Version 1 Applicability - RFC 2208 
> > 	RSVP Version 1 Message Processing Rules - RFC 2209 
> > 	RSVP Operation Over IP Tunnels - RFC 2746 
> > 	RSVP Cryptographic Authentication - RFC 2747 
> > 	RSVP Refresh Overhead Reduction Extensions - RFC 2961 
> > 	RSVP Cryptographic Authentication-New Message Type - RFC 3097 
> > 	Format of the RSVP DCLASS Object - RFC 2996
> > 	Specification of the Null Service Type - RFC 2997
> > 	A Framework For IntServ Operation Over Diffserv 
> Networks - RFC 2998
> > 	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.tx
> t.  GIST 
> > supports both IPv4 and IPv6.
> 
> The Next Steps in Signaling (NSIS) 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).  It proposes a two-layer architecture 
> consisting of a transport protocol and signaling application. 
> Relevant documents are under active development in the NSIS 
> WG. Some of the key documents under development:
> 
>   "GIST: General Internet Signaling Transport" (draft-ietf-nsis-ntlp)
> 
>   "NSLP for Quality-of-Service signalling" (draft-ietf-nsis-qos-nslp)
> 
>   "QoS-NSLP QSPEC Template" (draft-ietf-nsis-qspec)
> 
>   "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS
>   Classes" (draft-ietf-nsis-y1541-qosm)
> 
> > 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-tran
> sition-01.txt.
> 
> moved to later in document...
> 
> > QoS signaling interworking, IPv4<->IPv6
> > 
> > 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
> 
> I don't know what to say above, but the above draft does not 
> appear to be a WG document. I don't think it is appropriate 
> for us to reference the document given its non-IETF status.
> 
> But I agree with Bob that something like the following should go here:
> 
>   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.
> 
> > IPv4 / IPv6 interaction and transition
> >
> 
> 
> > 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.
> 
> Suggest simply saying:
> 
> The IETF has done much work on IPv4/IPv6 interaction and
> transition. In particular, see both the output and on-going work of
> the IPv6 Operations (v6ops) Working Group. In particular, the IETF has
> focussed on a "dual-stack" mode of operations, as documented in RFC
> 4313.
> 
> There is also on-going work on IPv6 transition issues for SIP, see: 
> ¡ÈIPv6 Transition in the Session Initiation Protocol (SIP)¡É
> (draft-ietf-sipping-v6-transition).
> 
> > IPv6 flow label
> > 
> > The IPv6 flow label is described in RFC 3697. In IPv4, a flow of IP
> > packets are traditionally defined as 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.
> 
> The IPv6 flow label is defined in RFC 3697. In IPv4, a flow of IP
> packets are traditionally defined as the tuple (source IP, destination
> IP, source port, destination port, transport protocol type). For a
> number or reasons, this approach is less viable in IPv6. For example,
> 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
> IPsec encryption. 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'd suggest dropping the above, as it doesn't add anything beyond the
> existing RFCs.
> 
> > 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.
> 
> Do we have an ID to cite? and is it an official WG document? If not,
> we probably should just drop the above paragraphs.
> 
> > 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.
> 
> Multihoming in IPv6 has been the focus for a lot of discussion both
> inside the IETF, within the operational community, and at the Regional
> Internet Registries (RIRs). Unlike with IPv4, current IPv6 RIR address
> allocation policies make it very difficult for end sites to obtain
> direct address assignments from an RIR. Instead, end sites are
> expected to get addresses from service providers.  All along it has
> been known that end-sites have a need for multihoming services.  For
> this reason the IETF created the Site Multihoming in IPv6 (multi6)
> Working Group.  Multi6 was tasked with defining the operational needs
> of a multihoming solution. Those resuls 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 of the WG 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 work is currently being carried out in
> Site Multihoming by IPv6 Intermediation (shim6) Working Group.
> 
> > 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.
> 
> Drop the above.
> 
> > 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.
> 
> I'm not sure I understand why Mobility is being called out for
> discussion. Is this a "NGN" topic? Mobility is _NOT_ what I normally
> think of as "network infrastructure". Its largely an e2e approach
> involving end nodes (mobile & correspondant nodes) and servers (Home
> Agents). It is built on top of a network, it is not part of the "core"
> network itself.  Also, there are a lot of IETF WGs that are doing IPv6
> work that might be related. E.g., autoconf/manet. Do we mention them
> all? What is the criteria for deciding  what to mention and what not?
> 
> Also, the above isn't entirely accurate. For example, there is no
> route optimization in MIPv4, so it doesn't make sense to say
> "especially the security model for route optimization is different".
> 
> > 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.
> 
> Last sentence should not be here at all. 
> 
> > 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.
> 
> This is too abstract/high-level for what we should be commmunicating
> to ITU-T.
> 
> > 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.
> 
> IMO, this entire section seems vague and I'm not really sure what it
> is trying to say (in the context of a clear message to ITU-T). I'd
> suggest dropping completely.
> 
> Or, just a short paragraph pointing the (large number of) WGs in this
> space.
> 
> > 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.
> 
> Drop the reference to the directorate. they should engage the 
> WG directly.
> 
> > 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.
> 
> Do we need the above? If so, shouldn't we say the same for other areas
> (like mobility)? And has ITU-T specifically requested such
> information? If not, why are we volunteering?
> 
> >  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.
> 
> The IETF appreciates the interest of Q.9/13 and the continuing
> cooperation between ITU and the IETF.  It should be noted that the
> contents of this statement are of a very general nature.  Please let
> us know if there are additional more specific questions concerning
> IETF technical work or its applicability to particular environments.
> In particular, we would welcome the opportunity to direct your members
> to appropriate IETF Working Groups to carry out the technical
> discussion directly with subject matter experts.
> 
> Thomas
> 
> 

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