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

Hi,

I agree with Thomas. The LS should be simple, mostly refer to content
that has been produced or is ongoing as WG items. I think trying to give
them some sort of list what has been produced with pointers (and some
textual padding to make the LS readable). I think this should be the
first step towards more cooperation and to attract interest from ITU-T
to work more in the future with the IETF - directly on the WG level.

Cheers,

Jonne.
On Mon, 2006-01-09 at 09:55 -0500, ext Thomas Narten wrote:
> 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.txt.  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-transition-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 its 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
> ipv6-dir@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipv6-dir

_______________________________________________
ipv6-dir mailing list
ipv6-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ipv6-dir