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.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 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
ipv6-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ipv6-dir