Subject: [ipv6-dir] Re: Updated document

From: Pekka Nikander <[email-masked]>
Date: Thu, 5 Jan 2006 16:01:55 +0200

> Please send comments!
> <q.9-sg13-liasion-20060105.doc>
>

If we want to include speculative and forward looking text, I propose  
the following for the "IPv4/IPv6 transition" bullet:

---

A potential future approach to IPv6/IPv4 interaction is to implement  
the so called identifier/locator split in some way.  Among the  
various potential approaches being considered, the approach used in  
the HIP working group (draft-ietf-hip-arch-03.txt, in RFC Editor  
Queue) is among the more developed.  The parallel HIP research group  
is studying the problems related to real life deployability of HIP.   
If later decided to be adopted, HIP or some other identifier/locator  
split approach may make the difference of IPv4 and IPv6 irrelevant,  
allowing nodes to be mobile and multi-homed between the two versions  
of IP, without any IP-version related visibility to the  
applications.  [Technical remark:  While the architectural approach  
taken by identifier/locator split is different from the current  
tunnelling and encapsulation approaches, at the actual data-transport  
protocol level there is little if any difference.  The differences  
lie in IP-layer state set up between peer nodes and at the APIs  
available to the upper layer protocols and applications.]

---

However, that text may be too speculative and/or something that  
cannot be considered as a part of the IETF consensus.  I am  
definitely biased here, and leave it for others to make the evaluation.

--Pekka

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

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 05 Jan 2006 16:03:40 -0500

Howdy,

 From a 30k foot perspective, looks good to me, with one
caveat -- I realize that the last para is "polite", but
I'm always concerned about setting expectations appropriately.

Your text:

"The IETF appreciates the interest of Q.9/13 and the good cooperation 
between ITU and the IETF. We are delighted to cooperate and are looking 
forward for further questions and input regarding the IETF technical work."

I think, perhaps:

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.

?

WRT from whom -- I'm happy if it comes from Margaret as AD of
the implicated WGs, and if need be I can help facilitate things
with the Tool.

Leslie.

Scott W Brim wrote:
> I've attached some marked-up Word.  It's your liaison but I have some
> suggestions.
> 
>   - Jonne's preamble and postamble
> 
>   - (Obviously) take out the text in italics, which was my summary of
>     what I thought they would want to hear.
> 
>   - Under IPv4/v6 interaction and transition, do you want to mention
>     softwires?
> 
>   - Significant editorial stuff like SCPT -> SCTP (see mark-up)
> 
> I've also proposed some smaller editorial stuff if you want it.  I
> hope I got the indentation right.
> 
> Finally, there's the question of who sends the liaison.  Kurtis,
> Margaret, Leslie ... ??  That's up to you all, but we should decide
> soon :-)
> 
> Thanks much ... Scott

---

From: Scott W Brim <[email-masked]>
Date: Thu, 05 Jan 2006 10:52:21 -0500

Thanks much ... Scott

---

From: [email-masked] (Scott Bradner)
Date: Thu, 5 Jan 2006 16:30:10 -0500 (EST)

Leslie is more directive and suggests:

looks good to me

Scott

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Jan 2006 10:16:10 +0100

> definitely biased here, and leave it for others to make the  

I personally would prefer to keep to existing situations. But that is  
just me. Others?

- kurtis -

---

From: Scott W Brim <[email-masked]>
Date: Fri, 06 Jan 2006 06:49:50 -0500

On 01/06/2006 06:28 AM, Brian E Carpenter allegedly wrote:
> I've lost track of the original request

To refresh everyone, the whole paragraph at the end of their liaison was:

    It would be very much appreciated if the IETF could provide input
    to study the impact of IPv6 to an NGN. Furthermore, it would be
    very helpful and useful for our further collaboration if the IETF
    could inform us of their standards plan regarding IPv6. We will
    also inform the IETF of our ideas in the near future and then
    commence creating Internet drafts to define our requirements.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Jan 2006 09:34:35 -0500

I just tried to review this thread, the current document, and the
liaison statements that are prompting our response. I must say, it's a
little bit unclear what ITU-T is asking for, and I'm a little
concerned about the current response and what it says (or more
specifically, how ITU-T will use it and whether the results will be
what the IETF wants).

>From what I was able to figure out, the most relevant liaison
statement is:

Scott W Brim <[email-masked]> writes:

> For those who might not have seen them, this came out of
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=127
> and https://datatracker.ietf.org/documents/LIAISON/file182.pdf

file182.pdf says:

> At WTSA-04, SG 13 was entrusted a new Question (Q.9/13, Impact of IPv6
> to an NGN) which mainly aims at developing requirements for an NGN
> using IPv6. Because Q.9/13 is in the starting phase of studying the
> use of IPv6 for NGN, the major concerns are currently to define how
> IPv6 can be used in the NGN and what the requirements of IPv6 for the
> NGN are. We believe that this is not overlapping with IETF standards
> activities, rather our activities would be seen as complementary for
> harmonizing IPv6 related standards relevant to NGN.
> 
> It would be very much appreciated if the IETF could provide input to
> study the impact of IPv6 to an NGN. Furthermore, it would be very
> helpful and useful for our further collaboration if the IETF could
> inform us of their standards plan regarding IPv6. We will also inform
> the IETF of our ideas in the near future and then commence creating
> Internet drafts to define our requirements.

>From the above, it's far from clear what we should be saying. Or is
there another document that outlines their request more clearly?

Looking at the current proposed response, I worry that it references
too many documents that aren't even "IETF standards". Should we be
doing that?

E.g., the document says:

> 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.

Should be  mentioning this explicitely? Are we somehow endorsing this?

Also, the multihoming section says too much and uses wording that
will be a hot button for some. E.g.,

> The IETF is currently considering extensions and, in the longer term,
> potential alternatives, to Mobile IPv6.

This is a very loaded statement and I'm not sure I even agree with
it. It all depends on how you define "mobility". More to the point,
such a statement in a liaison from the IETF needs review from our
mobility community, as I suspect they will not agree with the slant of
the wording. And is this something we should be communicating to
ITU-T?

Same goes for calling "mobike" and "alternative to" mobile IP.

The multihoming section also has too much text, IMO, some of which I
don't think we need to include. Like the mention of addresss
allocation  and stuff that is RIR territory.  I'm not sure why it's
included, and I not convinced its an adequate summary.

At a 50,000 foot level, I think we'd be better served with a set of
pointers to the (relevant) approved IETF standards track documents,
maybe mention some key IDs that are near completion on the standards
track, but we need to be much more  reserved in mentioning of
experimental track documents and random IDs that do not have strong
traction in the IETF at the present time.

I think it is a fair question to ask how this statement  should be
mentioning/positioning HIP.

Finally, shouldn't this statement be reviewed by the IPv6 community
prior to it being sent out? It would not be good to have the response
"surprise" our own community.

Again, from the 50K level, how do we expect ITU-T to use our response,
and what will they do with it? Will it have the desired (from our
perspective) result?

Thomas

---

From: Scott W Brim <[email-masked]>
Date: Fri, 06 Jan 2006 09:57:20 -0500

Filling in the bits I can respond to ...

> there another document that outlines their request more clearly?

Their charter is how to use IPv6 to meet ITU-T NGN scenario needs.
This liaison of theirs was in response to our liaison saying they
should not come up with solutions to their problems involving protocol
extensions on their own, and that they should do scenarios,
requirements, profiles etc. and bring those to the IETF for protocol
work.  They enthusiastically said yes (some of them already
participate).  They are looking at their requirements, looking at
IPv6, and doing a gap analysis.  In order to do that more effectively,
they asked: what is the IETF's "standards plan" for IPv6?  That is,
where is IPv6 going?  What's the roadmap?

> too many documents that aren't even "IETF standards". Should we be

They want a sense of where things are going.  If a draft is clearly
agreed to be headed toward standard, and it's relatively fundamental,
they would like to know about it.

> the wording. And is this something we should be communicating to

Assuming it is factual, I don't see the harm in communicating IETF's
direction to ITU-T, at least this Question.  They gladly acknowledge
the IETF's leadership, are looking forward to cooperation, and want to
know where they are being led.

> traction in the IETF at the present time.

Right.

> "surprise" our own community.

IMHO if the information in it is factual, what's to review?  You sort
of cover that in your other statements.

> and what will they do with it? Will it have the desired (from our

The desired result is that they feel confirmed in their idea that the
IETF is providing leadership, and have a good feeling about bringing
their requirements in (as drafts).  I think the liaison is on the
right track.  The issue I guess is content.

swb

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Jan 2006 18:22:19 +0100

Thomas,

> included, and I not convinced its an adequate summary.

I tried to explain what is IETF territory there or not. Do you think  
that is a bad idea? I don't feel strongly one way or the other. If  
you think the current text does not reflect that, any suggested  
rewording?

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Jan 2006 18:24:23 +0100

On 6 jan 2006, at 15.57, Scott W Brim wrote:

> In order to do that more effectively,

Well, the problem is that we don't really do road-maps as such.  
People submit ideas and they are evaluated...

So, while I agree with the concerns on what we are really replying  
to, we can't really do much more than reply with the current status  
of standardisation for the various areas they asked for.

- kurtis -

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 06 Jan 2006 16:42:14 -0500

(I expect someone is going to have to spring this from
the IPv6 directorate mailing list, as I am not a member).

I've read today's discussion of this document -- I see concerns,
but no suggested text.  Also, I understand that Kurtis has not
heard back from Margaret re. shipping this, so I'm willing
to send it but require further IAB nodding.

To deal with the concerns I've seen raised, I propose to
change the introductory paragraph (currently shown as a change
in this draft) to:

> 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.

I'll ask for a short last call within the IAB -- the document has
not substantively changed from the earlier version as seen.  So,
please let me/Kurtis know by noon Monday (US-ET) if this is a statement
you, as IAB members, are willing to support.

Leslie.

Kurt Erik Lindqvist wrote:
> 
> On 5 jan 2006, at 22.03, Leslie Daigle wrote:
> 
> Ok, Scott's text now with Leslie's suggested pre-amble. Margaret, I  
> hope you are fine with sending this?
> 
> Can I consider my self done with this now? I haven't seen any  comments 
> on this so I guess we are?
> 
> 
> BTW, I hope this is Margaret's correct email address? She should  anyway 
> be on the ipv6-dir mailinglist....
> 
> - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Jan 2006 10:18:30 +0100

Can I consider my self done with this now? I haven't seen any  
comments on this so I guess we are?

BTW, I hope this is Margaret's correct email address? She should  
anyway be on the ipv6-dir mailinglist....

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jan 2006 12:19:17 +0100

> I personally would prefer to keep to existing situations. But that is  

Strongly agree. I think we should keep anything speculative or unclear
out of this document - the danger of misinterpretation and wild
extrapolation is very high. We've often seen "the IETF is working on..."
turned into "the new IETF standard for..." by magic.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jan 2006 12:28:47 +0100

I've lost track of the original request, but shouldn't the QOS
section also say:

The Differentiated Services QOS mechanism (RFC 2474, RFC 2475)
is defined identically for IPv4 and IPv6, and in the case of
IPv6 is encoded in 6 bits of the Traffic Class octet in the
IPv6 header.

    Brian

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 06 Jan 2006 16:45:47 -0500

Full text, in pdf & word, to see the precise version I'm
talking about.

Leslie.

---

From: "Margaret Wasserman" <[email-masked]>
Date: Fri, 6 Jan 2006 18:49:56 -0500

This looks great!  Thanks to everyone who helped in putting it together.

I'd be happy to send it.  Scott Brim, could you tell me where/how I should
send it?

Thanks,
Margaret 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kurt Erik Lindqvist
> Sent: Friday, January 06, 2006 4:19 AM
> To: Leslie Daigle
> Cc: <[email-masked]> (Nokia-NRC/Helsinki) John; IAB 
> IAB; Scott W Brim; Margaret Wasserman; Bradner Scott; 
> [email-masked]
> Subject: Re: [ipv6-dir] Re: Updated document
> 
> 
> > WRT from whom -- I'm happy if it comes from Margaret as AD of the 
> > implicated WGs, and if need be I can help facilitate things 
> with the 
> > Tool.
> 
> Ok, Scott's text now with Leslie's suggested pre-amble. 
> Margaret, I hope you are fine with sending this?
> 
> BTW, I hope this is Margaret's correct email address? She 
> should anyway be on the ipv6-dir mailinglist....
> 
> - kurtis -
>

---

From: Scott W Brim <[email-masked]>
Date: Fri, 06 Jan 2006 18:58:26 -0500

> I'd be happy to send it.  Scott Brim, could you tell me where/how I should

I must be sleepier than I thought (I woke up at 2:30am).  I've lost
the liaison tool web page!  Could you poke around for it?  Leslie, can
you help?

---

From: Scott W Brim <[email-masked]>
Date: Fri, 06 Jan 2006 18:59:06 -0500

Anyway, the target address is <[email-masked]>.  That's the
SG13-specific secretariat address.

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Mon, 09 Jan 2006 15:53:03 +0200

Hi,

my comment is a bit late, but I think Leslie's clarification is very
good. Let's encourage them to participate directly in the work, instead
of sending LSes. (Yes, I've read the new text in the actual draft LS
version - looks good.)

Cheers,

Jonne.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Jan 2006 09:55:02 -0500

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

> 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".

> standards, is implemented in the commercial Boeing Connexion

Last sentence should not be here at all. 

> 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.  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

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Mon, 09 Jan 2006 17:08:31 +0200

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:
> > are in progress.  We also appreciate your understanding that,
> where works are in progress.  We also appreciate your
> > protocols.  See Analysis of Existing Quality-of-Service Signaling
> > Protocols RFC 4094. RSVP supports IPv6.  The major RSVP RFCs are:
>     
> signaling protocols have been identified.  See Analysis of Existing
> Quality-of-Service Signaling Protocols RFC 4094 or more
> > There is on-going work on IPv6 transition issues for SIP, see: IPv6
> > Transition in the Session Initiation Protocol (SIP) -
> > See: NSIS Operation Over IP Tunnels -
> IPv6 Transition in the Session Initiation Protocol (SIP)
> > would require a deep packet inspection in worst case. Some of the
> would require a deep packet inspection in worst case. Some of the
> > Last its worth noticing that RFC 3697 does not make any assumptions
> > flow-label field for its originally intended value, such as the
> > work in the NSIS WG.
> 
> > are summarized in the RFC 3582, Goals for IPv6 Site-Multihoming
> > Architectures. The multi6 working group concluded with an
> > trade-offs. These are described in RFC 4177, Architectural
> > Approaches to Multi-homing for IPv6. The conclusion was that the
> 3582, Goals for IPv6 Site-Multihoming Architectures.  The multi6
> 4177, Architectural Approaches to Multi-homing for IPv6. The
> > issues are addressed in RFC3032 MPLS Label Stack Encoding.  This

---

From: Scott W Brim <[email-masked]>
Date: Mon, 09 Jan 2006 10:22:53 -0500

<liaison hat> OK but please can we do whatever it takes to reach
closure on this today -- maybe tomorrow?  The meeting starts in one
week, and the TSB needs to process this as an input document.

>   IPv6 and IPv4 QOS.  Generally the IETF focuses on Internetworking,

<personal hat> I would delete the last sentence because it's debatable
in a couple of ways, and unnecessary in any case.

> I'd suggest dropping the above, as it doesn't add anything beyond the

<liaison hat> true but I believe it's worth calling it all out again,
to remind them that they shouldn't assume semantics in the flow label,
etc.  There was a thrust in that direction.

> discussion. Is this a "NGN" topic? 

Hugely so.  One of their key documents is on mobility and how IPv6
supports it.  Not just IP mobility but higher layer mobility,
fixed-mobile convergence, and so on.  One of the things they
originally proposed was that SCTP was the answer to their mobility
problems.  I pointed out a few and they backed off of that in the
latest version, to requirements and generic scenarios.  They are
actually quite aware of the mobility support capabilities, so you
don't need to say much, but for the sake of responding to their
interests, it would be good to leave this paragraph in.

That said, my burning desire at this point is to see this get out the
door, so if deleting this paragraph makes that happen, go for it.

> This is too abstract/high-level for what we should be commmunicating

Why?  They are trying to understand the IETF trajectory.  Are all of
these in the works, standards track or WG drafts?

(refrain) That said, my burning desire at this point is to see this
get out the door, so if deleting this paragraph makes that happen, go
for it.

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2006 10:40:35 +0100

I have no problems with this version. I don't understand the
mindset of the people asking the question well enough to judge
whether it's really on target. I wonder if we are missing some
general scene-setting at the beginning? Time is short to debate this,
but it's possible we should say something like

We remind the NGN community that IPv6 is a relatively conservative
replacement for IPv4, intentionally with no revolutionary features,
and that it is intended to overcome the addressing limitations and
some specific omissions in IPv4 without in any way fundamentally
changing the nature of the Internet. As such, we see very limited risk
and much to gain by unambiguous adoption of IPv6.

Or something.

   Brian

Kurt Erik Lindqvist wrote:
> 
> On 9 jan 2006, at 15.55, Thomas Narten wrote:
> 
> Me and Margaret chatted and I promised to do the edit. Which is  
> attached here. I _think_ that Thomas changes overlapped with Bob's  (but 
> I might have missed something) so I edited in Brians and Thomas  comments.
> 
> With two exceptions that I didn't know what to do with and I really  
> have a strong feeling one way or the other.
> 
> Where?
> This is now dropped. If Scott and Thomas agrees on what to do with it  I 
> am happy either way.
> 
>>
>>> Mobility.
>>>
> I just answered the questions :-)
> 
> Could we get some input on this from Pekka that wrote the text? I  have 
> no feelings one wy ro the other. I didn't make any changes here.
> 
>>
> Loa?
> This text is also left as is...
> 
> - kurtis -

---

From: Scott W Brim <[email-masked]>
Date: Tue, 10 Jan 2006 10:27:10 -0500

> and much to gain by unambiguous adoption of IPv6.

There's no question about adoption of IPv6.  They love it.  My
evaluation is that their mindset is more one of showing SG13 how well
IPv6 fits the NGN goals.  In order to do that better they (1) want a
roadmap from the IETF and (2) intend to bring some drafts in on
enhancements to "IPv6" (for a broad definition of the term) for the
gaps between NGN goals and IPv6 capabilities.  One of my intentions
was to encourage early review of their gap analyses and maybe show
them that IPv6 can already do what they want in some way.  That's why
I was very happy when Margaret suggested getting volunteer experts to
help.  It appears that they actually know a lot already, but could use
a little support from those who see the architectural vision.  Anyway,
I hope that after this meeting they will be able to send at least one
of their documents for review and response by ipv6dir.

swb

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 10 Jan 2006 17:32:23 +0100

> and much to gain by unambiguous adoption of IPv6.

I would be happy with that addition...

- kurtis -

---

From: Scott W Brim <[email-masked]>
Date: Wed, 11 Jan 2006 06:34:48 -0500

On 01/11/2006 01:25 AM, Lixia Zhang allegedly wrote:
> Couple specific comments:
> - if one wants to list RSVP standards: the base spec is missing from 
> the current list:
> 
>    [RFC 2205] "Resource ReSerVation Protocol (RSVP) --
>                Version 1 Functional Specification"

Added

> - About how to position SCTP: this version from Kurtis did not have  any
> mentioning about SCTP, but if we say anything at all, I would  suggest a
> statement in a positive way (perhaps something like "While  SCTP can be
> an effective approach to support multihoming at transport  protocol
> level, IETF is developing general solutions to support  multihoming at
> IP level").
> I too heard about ITU-T being a big fan of SCTP, like Thomas, I'd  tempt
> to say let them.

I understand that SCTP is very popular because of its success in
carrying SS7.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jan 2006 13:08:04 +0100

> I understand that SCTP is very popular because of its success in

Well, that's what it was designed for - have we any data about
actual deployment?

     Brian

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Wed, 11 Jan 2006 17:36:43 +0200

What is now the latest version of the doc? 

Cheers,

Jonne.

---

From: Scott W Brim <[email-masked]>
Date: Wed, 11 Jan 2006 15:46:54 -0500

> What is now the latest version of the doc? 

Hi.  The edits became smaller and finally we sent it.  See
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=158

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Thu, 12 Jan 2006 17:40:08 +0200

Hi,

thanks. Looks good.

Cheers,

Jonne.