Subject: Re: Open question and Critical dependencies
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: shim6 <[email-masked]>
Date: Wed, 30 Mar 2005 18:51:41 -0800

>  since I don't see anyone else chiming in with you.

yeah.  i noticed that too.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Thu, 31 Mar 2005 02:43:48 +0000
Date: Thu, 31 Mar 2005 02:37:35 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dave Crocker <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Dave

Dave Crocker wrote:
> On Tue, 29 Mar 2005 12:03:38 +0200, Brian E Carpenter wrote:
> 
>> Dave, please read the drafts. We aren't going to embed
>> the whole spec in the charter, surely?
> 
> 
> Brian,
> 
> A charter is supposed to explain its basis.  
> 
> A charter that sets up this sort of critical deployment dependency --
> especially when there has been such extended delays gaining deployment and use
> for the thing being depended on -- needs to explain the basis for that
> dependency.  
> 
> Please read Section 2 of the WG Guidelines document.

I personally believe that the revised charter fully meets those criteria,
but like quite a few other charters does so by reference to specific
documents. I don't plan to argue the point further, since I don't see
anyone else chiming in with you.

    Brian

Delivery-date: Wed, 30 Mar 2005 11:21:06 +0000
Date: Wed, 30 Mar 2005 13:20:35 +0200
From: Julien Laganier <[email-masked]>
Subject: Re: Open question and Critical dependencies
To: Dave Crocker <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, shim6 <[email-masked]>
Organization: SUN Microsystems, Inc.

On Tuesday 29 March 2005 09:53, Dave Crocker wrote:
> Brian,
>
> > > >  Forgive me, but I do not see what it is about shim6 that
> > > >  cannot work equally
> > > >  well for IPv4.
> >
> >  IPv4 doesn't have a 64 bit routing prefix.
> >  IPv4 doesn't have an interface identifier field.
> >  IPv4 doesn't have a flow label field.
> >  IPv4 doesn't have extension headers.
>
> I wasn't asking for a detailing of differences between 4 and 6.
>
> I was/am asking what it was about the shim work that requires
> taking advantage of features specific to 6.

Hi Dave,

FWIW, here are my answers to some of your questions:

(...)

> Does/will shim6 use the interface identifier field?  If so, how and
> why?

The size of the IID field (64 bits) make it possible to use strong 
crypto (HBA or CGA) without requiring infrastructure (e.g. a PKI), by 
embedding in the IID a mapping information (i.e. mapping from an IPv6 
address to a set of prefixes, or to a public key). 

With IPv4 it is not possible to embed in the address some mapping 
information, because there isn't sufficient room.

> Does/will shim6 rely on the flow label field?  Why?

The flow label field is a good means to embed host pair context 
identifier for shim6 in IPv6 packets.

> Does/will shim6 use extension headers?  Why?

That might be a simple and clean way to negotiate, at the IPv6 layer, 
the activation of shim6.

>
(...)
>

Thanks,

--julien

Delivery-date: Wed, 30 Mar 2005 01:12:37 +0000
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 29 Mar 2005 17:11:02 -0800
Subject: Re: Open question and Critical dependencies

On Tue, 29 Mar 2005 12:03:38 +0200, Brian E Carpenter wrote:
>  Dave, please read the drafts. We aren't going to embed
>  the whole spec in the charter, surely?

Brian,

A charter is supposed to explain its basis.  

A charter that sets up this sort of critical deployment dependency --
especially when there has been such extended delays gaining deployment and use
for the thing being depended on -- needs to explain the basis for that
dependency.  

Please read Section 2 of the WG Guidelines document.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Tue, 29 Mar 2005 10:04:00 +0000
Date: Tue, 29 Mar 2005 12:03:38 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dave Crocker <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Dave, please read the drafts. We aren't going to embed
the whole spec in the charter, surely?

    Brian

Dave Crocker wrote:
> Brian,
> 
> 
>>>> Forgive me, but I do not see what it is about shim6 that
>>>> cannot work equally
>>>> well for IPv4.
>>>>
>>
>> IPv4 doesn't have a 64 bit routing prefix.
>> IPv4 doesn't have an interface identifier field.
>> IPv4 doesn't have a flow label field.
>> IPv4 doesn't have extension headers.
> 
> 
> I wasn't asking for a detailing of differences between 4 and 6.  
> 
> I was/am asking what it was about the shim work that requires taking advantage 
> of features specific to 6.
> 
> Does/will shim6 do something special with the 64-bit routing prefix?  If so, 
> what?
> 
> Does/will shim6 use the interface identifier field?  If so, how and why?
> 
> Does/will shim6 rely on the flow label field?  Why?
> 
> Does/will shim6 use extension headers?  Why?
> 
> 
> 
> 
>> IPv4 doesn't have the same scaling goals as IPv6.
> 
> 
> so?  what are the technical characteristics of the shim work that distinguish 
> between these differences in goal?
> 
> 
> 
>> IPv4 does have widely deployed NAT already.
> 
> 
> Predicting that the end-user population is going to stop using something it 
> has come to rely on is just a tad dangerous.  
> 
> The fact that nat's are deployed for a variety of reasons keeps getting 
> ignored.
> 
> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
> 

Delivery-date: Tue, 29 Mar 2005 08:34:17 +0000
Subject: Re: Open question and Critical dependencies
From: Jeroen Massar <[email-masked]>
To: Thierry Ernst <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Tue, 29 Mar 2005 10:34:01 +0200

--=-vB8KxSx/SvnLf5u+j5J3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-03-29 at 17:18 +0900, Thierry Ernst wrote:
> > > Resistance to adoption of IPv6 in the planet where I live doesn't
> > > exists. I use IPv6 on a regular basis, even to send this mail - you
> > > can check this in my mail header:
> > > Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp
> > > [IPv6:2001:200:0:8803::53])
> > 
> > Unfortunately, the IETF servers (or the PSG one, in this case) don't 
> > support IPv6 so this is not the case. 
> Hum, is this reasonable that an IPv6 WG doesn't even have IPv6 resources
> ? What about having an additional page which could only be seen through
> IPv6 ? ;-)

http://www.ietf.org.sixxs.org
http://ops.ietf.org.sixxs.org

etc.... or use ipv4.sixxs.org for sites available in ipv6 or
ipv6.sixxs.org for sites available in ipv4 only. Works for Google and
many other sites too, but hopefully they will have an IPv6 capable
version of their selves sooner or later. Not that that helps for the WG
case, but it has been noted a number of times. Randy Bush is the person
to speak to in this case ;) You might want to ask him nicely.

> > However, there should be an IPv6
> >  address in the headers of this email.  :-)
> Yep, I checked !
> 
> Note I didn't say it would be sent with IPv6 all the way long from me to
> all recipients, but it was sent using IPv6 between my laptop (I of
> course use an IPv6 compliant mailer) and my mail server, which is
> located 50kms from where I work.

Unfortunately Cisco PIX's still don't support IPv6 otherwise there would
at least be IPv6 in my mailheaders between my mailer ands my relay
box...

> > > FYI, in my office, we couldn't even get enough IPv4 addresses for
> > > all desktop,
> > 
> > Strange.
> 
> Do you know how many IPv4 addresses have been allocated to each
> countries in the world ? Some have several per citizen, some have 1 per
> citizen, and some less than one. I met people from a Tunisian university
> and they told me they only have 16 global IPv4 addresses.

Then they should go to APNIC and request addresses, who will give them
to them. Just like all other RIR's do. As long as you can show the need
for the address space and pay the lir fee you can get them.

>  I'm quite
> lucky to live in Japan, but this is technology-speaking a very highly
> developped country, so there are no tradeoff between v4 and v6.
> 
> (we could have received more IPv4 addresses if we where willing to
> renumber - which we didn't want).

Then you should not claim that you can't get more addresses.

> > - of the "top 100 English language web sites" not one is reachable
> > over  IPv6
> > - of the "top 100 English language web sites" one times out for AAAA 
> > DNS requests
> > - of the 213 Amsterdam Internet Exchange member's main websites, 9 are
> >  reachable over IPv6 (up from unknown / 4 just under a year ago)
> > - of the 213 Amsterdam Internet Exchange members, 59 had an IPv6 
> > address enabled on (one of their) port(s)
> 
> Would you let us know how you were able to collect such statistics ? 

Google for "top 100 web sites" pick a couple of those lists and check
the listed sites for AAAA records, none of them have them, I don't even
have to check... :(

The latter two, he most likely did by counting the number of peers he
has on the AMS-IX and checking the member list of the AMS-IX and doing
AAAA lookups of their websites... Also on the AMS-IX a ping6 ff02::[1|2]
will give some nice results to who is on that link ;)

Greets,
 Jeroen

--=-vB8KxSx/SvnLf5u+j5J3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-vB8KxSx/SvnLf5u+j5J3--

Delivery-date: Tue, 29 Mar 2005 08:30:01 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Tue, 29 Mar 2005 10:29:38 +0200
To: Thierry Ernst <[email-masked]>

On 29-mrt-05, at 10:18, Thierry Ernst wrote:

>> Unfortunately, the IETF servers (or the PSG one, in this case) don't
>> support IPv6 so this is not the case.

> Hum, is this reasonable that an IPv6 WG doesn't even have IPv6 
> resources
> ?

No. They should fire the current secretariat and hire a dual-stack one.

> Note I didn't say it would be sent with IPv6 all the way long from me 
> to
> all recipients, but it was sent using IPv6 between my laptop (I of
> course use an IPv6 compliant mailer) and my mail server, which is
> located 50kms from where I work.

Doesn't look that way:

(What's the deal with the psg server not trusting our domain names, 
anyway?)

>>> FYI, in my office, we couldn't even get enough IPv4 addresses for
>>> all desktop,

>> Strange.

> Do you know how many IPv4 addresses have been allocated to each
> countries in the world ?

IP addresses aren't allocated to countries. The rules are pretty much 
identical for each of the regional internet registries, so for new 
requests, there shouldn't be any difference where on earth the request 
is made. Of course many ISPs find it useful to create an artificial 
scarceness to squeeze more money out of their customers and it MIGHT be 
possible that in some less developed countries the RIR fees are 
problematic, but compared to other internet-related expenses these fees 
aren't exorbitant.

> (we could have received more IPv4 addresses if we where willing to
> renumber - which we didn't want).

Aha, there the monkey comes out of the sleeve, to use a good Dutch 
proverb.

>> Some random data points:

>> - of the "top 100 English language web sites" not one is reachable
>> over  IPv6
>> - of the "top 100 English language web sites" one times out for AAAA
>> DNS requests
>> - of the 213 Amsterdam Internet Exchange member's main websites, 9 are
>>  reachable over IPv6 (up from unknown / 4 just under a year ago)
>> - of the 213 Amsterdam Internet Exchange members, 59 had an IPv6
>> address enabled on (one of their) port(s)

> Would you let us know how you were able to collect such statistics ?

Simple: fire up tcpdump -p ip6 and port 80 and then visit 
http://www.ams-ix.net/connected/ and start clicking. For the top 100 
list I found something that I'm sure isn't the actual top 100 list but 
for my purposes that doesn't really matter.

Delivery-date: Tue, 29 Mar 2005 08:13:49 +0000
Date: Tue, 29 Mar 2005 17:18:20 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: Open question and Critical dependencies
Organization: Keio University

> > Resistance to adoption of IPv6 in the planet where I live doesn't
> > exists. I use IPv6 on a regular basis, even to send this mail - you
> > can check this in my mail header:
> > Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp
> > [IPv6:2001:200:0:8803::53])
> 
> Unfortunately, the IETF servers (or the PSG one, in this case) don't 
> support IPv6 so this is not the case. 
Hum, is this reasonable that an IPv6 WG doesn't even have IPv6 resources
? What about having an additional page which could only be seen through
IPv6 ? ;-)

> However, there should be an IPv6
>  address in the headers of this email.  :-)
Yep, I checked !

Note I didn't say it would be sent with IPv6 all the way long from me to
all recipients, but it was sent using IPv6 between my laptop (I of
course use an IPv6 compliant mailer) and my mail server, which is
located 50kms from where I work.

> > FYI, in my office, we couldn't even get enough IPv4 addresses for
> > all desktop,
> 
> Strange.

Do you know how many IPv4 addresses have been allocated to each
countries in the world ? Some have several per citizen, some have 1 per
citizen, and some less than one. I met people from a Tunisian university
and they told me they only have 16 global IPv4 addresses. I'm quite
lucky to live in Japan, but this is technology-speaking a very highly
developped country, so there are no tradeoff between v4 and v6.

(we could have received more IPv4 addresses if we where willing to
renumber - which we didn't want).

> >> When something take 10 years to get to the point of starting
> >> infrastructure  deployment, there is usually a rather basic
> >problem. > In particular, the world  has repeatedly seen promises of
> >the next > great technology that will see grand  deployments "soon in
> >the future" > that somehow keep being in the future, rather  than
> >now.
> 
> > When this 10 years period started ? If you refer to the time it was
> > first introduced at the IETF, it doesn't hold, as it takes time to
> > publish RFC, test implementation and market produst.
> 
> Right. Both claims of success and claims of failure are premature. And
>  in my opinion, dual stack servers weren't really deployable until the
>  
> addition of the IPV6_V6ONLY socket option, and IPv6 only clients still
>  aren't deployable due to lack of a resolving DNS server discovery 
> mechanism. The fact that the first IPv6 RFCs were published 9.3 years 
> ago is only relevant upto a point.
> 
> The truth is that nothing similar enough to the transition from IPv4
> to  IPv6 has happened in the past to make any conclusions based on it
> worth  the air and spit necessary to utter them. The only thing we
> know is  that predictions are notoriously hard, especially when they
> concern the  future. But I challenge anyone to show me how we could
> reasonably still  be using IPv4 in the year 2030.
> 
> > IPv6 is already deploying.
> 
> Some random data points:
> 
> - of the "top 100 English language web sites" not one is reachable
> over  IPv6
> - of the "top 100 English language web sites" one times out for AAAA 
> DNS requests
> - of the 213 Amsterdam Internet Exchange member's main websites, 9 are
>  reachable over IPv6 (up from unknown / 4 just under a year ago)
> - of the 213 Amsterdam Internet Exchange members, 59 had an IPv6 
> address enabled on (one of their) port(s)

Would you let us know how you were able to collect such statistics ? 

Thierry

Envelope-to: [email-masked]
Delivery-date: Tue, 29 Mar 2005 08:07:25 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Thierry Ernst <[email-masked]>
cc: [email-masked]
Subject: Re: Open question and Critical dependencies 
Date: Tue, 29 Mar 2005 10:07:00 +0200

 In your previous mail you wrote:

   When this 10 years period started ?

=> I have a nice answer to this question...

[email-masked]

Delivery-date: Tue, 29 Mar 2005 08:01:57 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Tue, 29 Mar 2005 10:01:37 +0200
To: Thierry Ernst <[email-masked]>

On 29-mrt-05, at 9:27, Thierry Ernst wrote:

>> After 10 years, we ought to deal with the reality that there is
>> significant  resistance to adoption.

> Resistance to adoption of IPv6 in the planet where I live doesn't
> exists. I use IPv6 on a regular basis, even to send this mail - you can
> check this in my mail header:
> Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp
> [IPv6:2001:200:0:8803::53])

Unfortunately, the IETF servers (or the PSG one, in this case) don't 
support IPv6 so this is not the case. However, there should be an IPv6 
address in the headers of this email.  :-)

> FYI, in my office, we couldn't even get enough IPv4 addresses for all
> desktop,

Strange.

>> When something take 10 years to get to the point of starting
>> infrastructure  deployment, there is usually a rather basic problem.
>> In particular, the world  has repeatedly seen promises of the next
>> great technology that will see grand  deployments "soon in the future"
>> that somehow keep being in the future, rather  than now.

> When this 10 years period started ? If you refer to the time it was
> first introduced at the IETF, it doesn't hold, as it takes time to
> publish RFC, test implementation and market produst.

Right. Both claims of success and claims of failure are premature. And 
in my opinion, dual stack servers weren't really deployable until the 
addition of the IPV6_V6ONLY socket option, and IPv6 only clients still 
aren't deployable due to lack of a resolving DNS server discovery 
mechanism. The fact that the first IPv6 RFCs were published 9.3 years 
ago is only relevant upto a point.

The truth is that nothing similar enough to the transition from IPv4 to 
IPv6 has happened in the past to make any conclusions based on it worth 
the air and spit necessary to utter them. The only thing we know is 
that predictions are notoriously hard, especially when they concern the 
future. But I challenge anyone to show me how we could reasonably still 
be using IPv4 in the year 2030.

> IPv6 is already deploying.

Some random data points:

- of the "top 100 English language web sites" not one is reachable over 
IPv6
- of the "top 100 English language web sites" one times out for AAAA 
DNS requests
- of the 213 Amsterdam Internet Exchange member's main websites, 9 are 
reachable over IPv6 (up from unknown / 4 just under a year ago)
- of the 213 Amsterdam Internet Exchange members, 59 had an IPv6 
address enabled on (one of their) port(s)

Delivery-date: Tue, 29 Mar 2005 07:54:25 +0000
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>, Dave Crocker <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 28 Mar 2005 23:53:17 -0800
Subject: Re: Open question and Critical dependencies

Brian,

> > >  Forgive me, but I do not see what it is about shim6 that
> > >  cannot work equally
> > >  well for IPv4.
> > >
>  IPv4 doesn't have a 64 bit routing prefix.
>  IPv4 doesn't have an interface identifier field.
>  IPv4 doesn't have a flow label field.
>  IPv4 doesn't have extension headers.

I wasn't asking for a detailing of differences between 4 and 6.  

I was/am asking what it was about the shim work that requires taking advantage 
of features specific to 6.

Does/will shim6 do something special with the 64-bit routing prefix?  If so, 
what?

Does/will shim6 use the interface identifier field?  If so, how and why?

Does/will shim6 rely on the flow label field?  Why?

Does/will shim6 use extension headers?  Why?

>  IPv4 doesn't have the same scaling goals as IPv6.

so?  what are the technical characteristics of the shim work that distinguish 
between these differences in goal?

>  IPv4 does have widely deployed NAT already.

Predicting that the end-user population is going to stop using something it 
has come to rely on is just a tad dangerous.  

The fact that nat's are deployed for a variety of reasons keeps getting 
ignored.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Tue, 29 Mar 2005 07:32:04 +0000
Date: Tue, 29 Mar 2005 16:36:35 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: proposed text for charter
Organization: Keio University

> Catching up on some back mail, I'd like to comment that IMO, the
> charter text:
> 
> > o  The solution must not cause problems for mobility. That is, it
> >     should be possible to continue using Mobile IPv6 even when using
> >     shim6 simultaneously. However, any optimizations or advanced
> >     configurations are out of scope for shim6.
> 
> is sufficient.
I don't think so.
 
> Thierry said:
> 
> > I would suggest to write "should be possile to continue using
> > mobility support protocols such as Mobile IPv6 land NEMO Basic
> > Support"
> > 
> > An additional item such as the following one would be useful:
> > 
> > - The WG will ensure that various mechanisms defined within other
> > IETF WGs will continue to work when using shmi6 simultaneously.  To
> > achieve this, the Shim6 WG will interact with other WGs when needed,
> > and may place requirements on the protocols developed by those WGs.
> 
> I disagree with this addtion, as it is not clear to me how shim6 would
> interact with these solutions, or what deployment models folks have in
> their mind.  I  agree with Erik's general scetch of shim6 - mip6
> interaction, but I am not sure if everyone has come to agreement.  I
> could think of many possible interactions -  running MIPv6 over SHIM6,
> for example.  What would it mean to run shim6 with fmip or hmip?  With
> respect to NEMO, are the multiple prefixes advertised over the NEMO
> link or would there be both a nemo-aware interface active and another
> non-NEMO interface.  All of these questions are secondary in nature,
> and I think we should actually get some of the basic shim6 work done
> before opening these boxes.

The best way for the (potential) Shim6 WG is to add such an item in the
charter and have some interested people doing the analysis. These
people may or may not consider scenarios etc, but at least we will be
aware of what interacting Shim6 and MIP6 means. Note this doesn't mean
that Shim6 would work on mobility (if it is understood this way then I
didn't express myself correctly). I think Jim and Erik caught what I'm
trying to say.

Thierry.

Delivery-date: Tue, 29 Mar 2005 07:22:56 +0000
Date: Tue, 29 Mar 2005 16:27:21 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: Open question and Critical dependencies
Organization: Keio University

> Yes, multi6 was chartered to work on 6.  yes, a focus on 6 dominated. 
> but some folks seem to be forgetting that this is a new working group
> and it  is getting a new charter.  if this is merely a continuation of
> the multi6  working group, then perhaps the current effort should be
> characterized as a  rechartering of multi6?

Another option is for you to gather with other people and create a IPv4
WG. This was done for Mobile IPv6 with MIP6 WF and MIP4 WG. 

> >  That is invalid comparison, OSI was a completely new protoocol and
> >  IPv6 is an extension to the Internet model and Ipv6 is being
> >  deployed and
> 
> The original proposal by Steve Deering was for something that could
> reasonably  have been treated as an IP upgrade.  
> 
> The current IPv6 is far more complex and disruptive.  Adopting it is
> the same  as adopting an entirely new internetworking protocol.  
> 
> After 10 years, we ought to deal with the reality that there is
> significant  resistance to adoption.

Resistance to adoption of IPv6 in the planet where I live doesn't
exists. I use IPv6 on a regular basis, even to send this mail - you can
check this in my mail header:
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp
[IPv6:2001:200:0:8803::53])

FYI, in my office, we couldn't even get enough IPv4 addresses for all
desktop, so we have to rely on NAT which breaks many things which we
cannot experiment. We don't have such trouble when we use Pv6. 

> On Tue, 29 Mar 2005 08:46:13 +0900, Thierry Ernst wrote:
> >  Are you arguing that IPv6 deployment is not underway ?  
> 
> When something take 10 years to get to the point of starting
> infrastructure  deployment, there is usually a rather basic problem. 
> In particular, the world  has repeatedly seen promises of the next
> great technology that will see grand  deployments "soon in the future"
> that somehow keep being in the future, rather  than now.

When this 10 years period started ? If you refer to the time it was
first introduced at the IETF, it doesn't hold, as it takes time to
publish RFC, test implementation and market produst.  As I wrote, I use
IPv6 today, and many other people do so for a longer time than me.  Of
course, I will have my computer continue to talk IPv4 as long as some
IPv4 computers are IPv4 only. 

> Sometimes, those deployments actually do occur and I think it will be
> good if  this is one of them.  However the history of efforts that
> experience such  rolling delays is rather dismal.

IPv6 is already deploying.

Thierry

Delivery-date: Tue, 29 Mar 2005 07:06:27 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Tue, 29 Mar 2005 10:02:58 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi all,

Catching up on some back mail, I'd like to comment that IMO, the charter
text:

> o  The solution must not cause problems for mobility. That is, it
>     should be possible to continue using Mobile IPv6 even when using
>     shim6 simultaneously. However, any optimizations or advanced
>     configurations are out of scope for shim6.

is sufficient.

Thierry said:

> I would suggest to write "should be possile to continue using mobility
> support protocols such as Mobile IPv6 land NEMO Basic Support"
> 
> An additional item such as the following one would be useful:
> 
> - The WG will ensure that various mechanisms defined within other IETF
> WGs will continue to work when using shmi6 simultaneously.  To achieve
> this, the Shim6 WG will interact with other WGs when needed, and may
> place requirements on the protocols developed by those WGs.

I disagree with this addtion, as it is not clear to me how shim6 would interact
with these solutions, or what deployment models folks have in their mind.  I 
agree with Erik's general scetch of shim6 - mip6 interaction, but I am not sure
if everyone has come to agreement.  I could think of many possible interactions - 
running MIPv6 over SHIM6, for example.  What would it mean to run shim6 with fmip
or hmip?  With respect to NEMO, are the multiple prefixes advertised over the NEMO
link or would there be both a nemo-aware interface active and another non-NEMO
interface.  All of these questions are secondary in nature, and I think we should
actually get some of the basic shim6 work done before opening these boxes.

Finally, Brian says:

> Well, I'd want to see a walkthrough to be sure that there aren't tricky
> cases where the change of locators forced by shim6 would cause perverse
> routing due to MIP6, or where a change of c/o address due to  MIP6 would
> confuse shim6. (Incidentally there are similar questions if we try to run
> SCTP over shim6.) I just don't want charter language that later proves
> to be mathematically impossible to meet. It goes without saying that
> interworking is highly desirable.

Which I basically agree with.  I think we have to have a stable understanding
of how SHIM6 works before going onto these topics.

John

Delivery-date: Tue, 29 Mar 2005 06:57:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Tue, 29 Mar 2005 09:55:56 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

> Dave Crocker wrote:
> >>> Forgive me, but I do not see what it is about shim6 that
> >>> cannot work equally
> >>> well for IPv4.  
> 
> IPv4 doesn't have a 64 bit routing prefix.
> IPv4 doesn't have an interface identifier field.
> IPv4 doesn't have a flow label field.
> IPv4 doesn't have extension headers.
> IPv4 doesn't have the same scaling goals as IPv6.
> IPv4 does have widely deployed NAT already.
> 
> It just makes no sense to do this for IPv4.

For what its worth, I completely agree with Brian on this.  I'd like
to add that lack of a multihoming solution does create a certain
deployment barrier - i.e. - IPv6 needs a multihoming solution, so 
I'd like to focus our energies on tasks that are needed.

John

Delivery-date: Tue, 29 Mar 2005 06:35:10 +0000
Date: Tue, 29 Mar 2005 08:34:53 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dave Crocker <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Dave Crocker wrote:
>>> Forgive me, but I do not see what it is about shim6 that
>>> cannot work equally
>>> well for IPv4.  

IPv4 doesn't have a 64 bit routing prefix.
IPv4 doesn't have an interface identifier field.
IPv4 doesn't have a flow label field.
IPv4 doesn't have extension headers.
IPv4 doesn't have the same scaling goals as IPv6.
IPv4 does have widely deployed NAT already.

It just makes no sense to do this for IPv4.

    Brian

Delivery-date: Tue, 29 Mar 2005 06:16:07 +0000
Date: Tue, 29 Mar 2005 08:15:23 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Erik Nordmark <[email-masked]>
CC: Jari Arkko <[email-masked]>, "Bound, Jim" <[email-masked]>, Thierry Ernst <[email-masked]>, shim6 <[email-masked]>
Subject: Re: proposed text for charter

Erik Nordmark wrote:
> Brian E Carpenter wrote:
> 
>> Well, I disagree. This may amount to asking for the
>> impossible. We can properly require a shim6 implementation to
>> co-exist with mobility implementations, but we cannot require it
>> to operate simultaneously with them; that may turn out to be
>> simply impossible. As I wrote a few days ago, it may be necessary
>> to instruct shim6 to switch itelf off when some other functions
>> are switched on.
> 
> 
> While I don't have a problem with the charter not committing to solving 
> this problem, I don't see it as being as hard as you think.
> 
> We have shim6, which says it will be transparent to what runs of top of 
> it, be it TCP, UDP, ICMP, or anything else.
> 
> We have MIPv6, which is transparent to what runs on top of it the same way.
> 
> Thus both layering shim6 over mipv6, and layering mipv6 over shim6, 
> should work in the sense that the protocol mechanisms continue to 
> function. Whether either or both combinations provide a useful combined 
> "service" is a different matter, but it seems to me that the shim6 
> layered over mipv6 can be quite useful in the case of a mobile IPv6 node 
> which has multiple home addresses, perhaps from independent home agents, 
> where the shim6 overlay would could be used to create a system where a 
> home agent (or the network in which the home agent resides) is not a 
> single point of failure.

Well, I'd want to see a walkthrough to be sure that there aren't tricky
cases where the change of locators forced by shim6 would cause perverse
routing due to MIP6, or where a change of c/o address due to MIP6 would
confuse shim6. (Incidentally there are similar questions if we try to run
SCTP over shim6.) I just don't want charter language that later proves
to be mathematically impossible to meet. It goes without saying that
interworking is highly desirable.

    Brian

Delivery-date: Tue, 29 Mar 2005 00:35:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Mon, 28 Mar 2005 19:35:29 -0500
From: "Bound, Jim" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "shim6" <[email-masked]>

> > >  Forgive me, but I do not see what it is about shim6 that
> > >  cannot work equally
> > >  well for IPv4.  
> > >
> >  It has to do with implementation and time to market.  
> shims will have to
> >  map to addresses and data structures for IPv6 and that is 
> x amount of
> >  work.  Adding IPv4 increases that work to deliver.
> 
> In the scheme of design and implementation details for shim6, 
> it would be 
> interesting to see the analysis that showed support for IPv4 
> as adding any 
> interesting amount of work, particularly in light of the 
> benefit of that would 
> accrue from supporting the current installed base of IPv4 platforms.

I am not into building charters but I don't support this and off this
topic. I have made my statements we can agree to not agree.

That being said of course I will look at this as implementor or I would
be stupid as IPv4 is all over the stack :--)

> 
> 
> >  The point of this work has always been to focus on an IPv6 
> solution.
> 
> Actually, that's not true.  a number of the proposals 
> supported 4 and 6.

I was speaking of my interpretation of the mission and objective and my
recollection is it was IPv6.

> 
> Yes, multi6 was chartered to work on 6.  yes, a focus on 6 dominated.

Fair analysis and interpretation.  But we have enough work to do to
focus on IPv6.

> 
> but some folks seem to be forgetting that this is a new 
> working group and it 
> is getting a new charter.  if this is merely a continuation 
> of the multi6 
> working group, then perhaps the current effort should be 
> characterized as a 
> rechartering of multi6?

I leave that to you all to debate charter.

> 
> 
> > >  It is one thing to exclude IPv4 if the work somehow,
> > >  fundamentally, depends on
> > >  the distinctive characteristics of IPv6.
> > >
> >  I suggest it does as we define mechansims to make the shim work.
> 
> It is difficult to guess how a charter can ignore an 
> installed base of 
> hundreds of millions of machines, with nothing more than a 
> guess about 
> possible future work.  
> 
> Normally, that sort of decision ought to have some technical basis.

I never speak from any position but a technical basis.  The work for
IPv6 has been sent by others.  I think it is plenty of work for this
working group.

> > >  My point is that NATs exist on a very large scale and they
> > >  seem to exist for a
> > >  variety of reasons.
> > >
> >  They exist for IPv4 they do not have to exist for IPv6
> 
> That is a reasonable belief, but there is no operational 
> basis for knowing 
> that the market will magically get rid of NATs.  

Well those of us driving IPv6 deployment are working very hard to make
this happen.

> 
> As I say, that is a very, very large gamble to take, absent 
> solid knowledge 
> about end-user criteria.  The IETF has always railed against 
> NATs; the market 
> has chosen to use them in spite of our expert opinion.

I agree but there will be many disruptive technologies that will
influence IPv6 at the same time IPv6 is coming to the Internet.  The
need for end-to-end is great and there is real revenue on the table to
support the process.

> 
> 
> >  I think NAT is orthogonal to the work for shim6 
> technically and this
> >  discussion is moot. shim6 will not benefit or detract from 
> NAT. In any
> >  form technically.
> 
> Actually, it's not.  NATs often know quite a bit of state 
> about an association 
> and, therefore, are likely to take exception to a transport 
> connection 
> suddently starts using a different IP Address. As I said, if 
> this were not the 
> case, MAST would have been running last year.

My view is most NAT is in a router most shim work is in end systems.

> 
> 
> > >  I hope you realize how much this language echoes OSI
> > >  predictions made long
> > >  ago.
> > >
> >  That is invalid comparison, OSI was a completely new 
> protoocol and IPv6
> >  is an extension to the Internet model and Ipv6 is being 
> deployed and
> 
> The original proposal by Steve Deering was for something that 
> could reasonably 
> have been treated as an IP upgrade.  
> 
> The current IPv6 is far more complex and disruptive.  
> Adopting it is the same 
> as adopting an entirely new internetworking protocol.  

I don't agree with that extreme but that is not a useful discussion for
this working group and could be a huge rat hole technically.

> 
> After 10 years, we ought to deal with the reality that there 
> is significant 
> resistance to adoption.

It is not resistance it is dot-bomb from to many that listened to
marketing people masquerading as engineers, Telcos being hurt by 3G
cost, and generally economic conditions.  That business climate is
changing now and also the first products were not done until 2000 and it
has taken us 4 years to truly test it etc. So 10 years is not
unreasonable to me at all. I have a slide set I do with next barriers to
deployment once I have them at URL location I can share them.  A big
barrier is applications but now all the large ERP apps are in process
and Microsoft Longhorn release in 2006 will be a key point on the Ipv6
deployment line of sight.  I could on and on with current deployment in
process and in Asia most dominant.  Not sure this conversation is useful
to the working group though?

> 
> 
> >  No one has done with the IPv6 deployment strategy at all.  
> IPv6 greatest
> >  business and operational benefit is that it can restore 
> the end-to-end
> >  model of networking and security.  
> 
> and which users have been demanding that restoration?

DOD's world wide, Providers, 3G TEMs, and WiFi Multimedia. 

> 
> 
> 
> On Tue, 29 Mar 2005 08:46:13 +0900, Thierry Ernst wrote:
> >  Are you arguing that IPv6 deployment is not underway ?  
> 
> When something take 10 years to get to the point of starting 
> infrastructure 
> deployment, there is usually a rather basic problem.  In 
> particular, the world 
> has repeatedly seen promises of the next great technology 
> that will see grand 
> deployments "soon in the future" that somehow keep being in 
> the future, rather 
> than now.

Ditto from above.

> 
> Sometimes, those deployments actually do occur and I think it 
> will be good if 
> this is one of them.  However the history of efforts that 
> experience such 
> rolling delays is rather dismal.

I don't agree the delays was for lack of want or need as I state above,
and we are now in opinion land for sure and two different views for
speculation.

/jim

> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
> 

Delivery-date: Tue, 29 Mar 2005 00:13:17 +0000
From: Dave Crocker <[email-masked]>
To: "Bound, Jim" <[email-masked]>, shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 28 Mar 2005 16:11:49 -0800
Subject: RE: Open question and Critical dependencies

> >  Forgive me, but I do not see what it is about shim6 that
> >  cannot work equally
> >  well for IPv4.  
> >
>  It has to do with implementation and time to market.  shims will have to
>  map to addresses and data structures for IPv6 and that is x amount of
>  work.  Adding IPv4 increases that work to deliver.

In the scheme of design and implementation details for shim6, it would be 
interesting to see the analysis that showed support for IPv4 as adding any 
interesting amount of work, particularly in light of the benefit of that would 
accrue from supporting the current installed base of IPv4 platforms.

>  The point of this work has always been to focus on an IPv6 solution.

Actually, that's not true.  a number of the proposals supported 4 and 6.

Yes, multi6 was chartered to work on 6.  yes, a focus on 6 dominated.

but some folks seem to be forgetting that this is a new working group and it 
is getting a new charter.  if this is merely a continuation of the multi6 
working group, then perhaps the current effort should be characterized as a 
rechartering of multi6?

> >  It is one thing to exclude IPv4 if the work somehow,
> >  fundamentally, depends on
> >  the distinctive characteristics of IPv6.
> >
>  I suggest it does as we define mechansims to make the shim work.

It is difficult to guess how a charter can ignore an installed base of 
hundreds of millions of machines, with nothing more than a guess about 
possible future work.  

Normally, that sort of decision ought to have some technical basis.

> >  It is another to
> >  exclude it because
> >  of an arbitrary preference.  IPv4 is the installed base.
> >
>  It is also because that is the work focus we agreed upon.

To repeat:  this is to be a new working group and is formulating a new 
charter.  Nothing has yet been agreed on.

> >  My point is that NATs exist on a very large scale and they
> >  seem to exist for a
> >  variety of reasons.
> >
>  They exist for IPv4 they do not have to exist for IPv6

That is a reasonable belief, but there is no operational basis for knowing 
that the market will magically get rid of NATs.  

As I say, that is a very, very large gamble to take, absent solid knowledge 
about end-user criteria.  The IETF has always railed against NATs; the market 
has chosen to use them in spite of our expert opinion.

>  I think NAT is orthogonal to the work for shim6 technically and this
>  discussion is moot. shim6 will not benefit or detract from NAT. In any
>  form technically.

Actually, it's not.  NATs often know quite a bit of state about an association 
and, therefore, are likely to take exception to a transport connection 
suddently starts using a different IP Address. As I said, if this were not the 
case, MAST would have been running last year.

> >  I hope you realize how much this language echoes OSI
> >  predictions made long
> >  ago.
> >
>  That is invalid comparison, OSI was a completely new protoocol and IPv6
>  is an extension to the Internet model and Ipv6 is being deployed and

The original proposal by Steve Deering was for something that could reasonably 
have been treated as an IP upgrade.  

The current IPv6 is far more complex and disruptive.  Adopting it is the same 
as adopting an entirely new internetworking protocol.  

After 10 years, we ought to deal with the reality that there is significant 
resistance to adoption.

>  No one has done with the IPv6 deployment strategy at all.  IPv6 greatest
>  business and operational benefit is that it can restore the end-to-end
>  model of networking and security.  

and which users have been demanding that restoration?

On Tue, 29 Mar 2005 08:46:13 +0900, Thierry Ernst wrote:
>  Are you arguing that IPv6 deployment is not underway ?  

When something take 10 years to get to the point of starting infrastructure 
deployment, there is usually a rather basic problem.  In particular, the world 
has repeatedly seen promises of the next great technology that will see grand 
deployments "soon in the future" that somehow keep being in the future, rather 
than now.

Sometimes, those deployments actually do occur and I think it will be good if 
this is one of them.  However the history of efforts that experience such 
rolling delays is rather dismal.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Mon, 28 Mar 2005 23:42:11 +0000
Date: Tue, 29 Mar 2005 08:46:13 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: Open question and Critical dependencies
Organization: Keio University

Dave Crocker <[email-masked]> wrote:
> > >  2. Why is shim6 limited to IPv6?  What is it about the
> > >  problem space and/or the solution space that is required to
> > >  exclude IPv4?
> > >
> >  First because we have no chance of solving the IPv4 problem. 
> 
> Forgive me, but I do not see what it is about shim6 that cannot work
> equally  well for IPv4.  That is really an underlying technical
> question I am trying to  ask.
> 
> It is one thing to exclude IPv4 if the work somehow, fundamentally,
> depends on  the distinctive characteristics of IPv6.  It is another to
> exclude it because  of an arbitrary preference.  IPv4 is the installed
> base.

I second that Shim6 is a (proposed) WG for IPv6, and in such a case it
**doesn't** have to deal with IPv4 backporting (on the other hand it
**may** have to deal with transition mechanisms, i.e. compatible with
the installed IPv4 base).

> > >  3. What happens to shim6 if it must operate through a NAT?
> > >
> >  If this is for IPv6 the deployment efforts are trying to eliminate
> >  NAT as majority view out of the IETF in the deployment community.
> 
> I am not arguing about the IETF religion against NATs, or even about
> the  legitimate feeling that NATs are messy and the IP architectural
> world would be  better without them.
> 
> My point is that NATs exist on a very large scale and they seem to
> exist for a  variety of reasons.  
> 
> To require that IPv6 be used without NATs is to assert a restriction
> on  current operational practice that is extremely risky, in terms of
> the  willingness of operations staff to concur.  Hence, it imposes a
> very high  barrier to adoption, given the network operations models
> for most IT staff and  home users.
> 
> In other words, we cannot make NATs go away simply because of IETF
> opinion.   It would, therefore, be wise for an IETF effort either to
> be NAT-neutral, when  possible, or to deal with their likely presence
> explicitly and constructively.

I think it's the responsability of the IETF to state loudly that NAT is
a bad thing. Of course, the decision to use NAT or not doesn't belong to
the IETF - an engineering body - but to the people defining the usage of
the Internet. As good engineers, we have the responsability to inform
the people defining the usages that they should not use NAT. Like
engineers at NASA have the responsability to tell their managers that
the shuttle should not take off. 

So, we don't have to make things work for NATs in IPv6. If they use NAT
anyway, people defining usages will bear the cost and the
responsability.

(if we make things work for NATs, it's like saying, well, NAT is a bad
thing, but well, here is the solution. I don't buy this). 

> > >  While both outcomes are appealing, all
> > >  operational history to date suggests that those outcomes are,
> > >  at best, far
> > >  into the future, if they will occur at all.  (Predictions of
> > >  changes to the
> > >  installed base of widely-adopted services are almost always
> > >  wrong.)
> > >
> >  Don't agree.  IPv6 deployment is infrastructure stage now and
> >  equipement purchases to support IPv6 are in process and transition
> >  planning within
> 
> I hope you realize how much this language echoes OSI predictions made
> long  ago.  It was an interesting example of wishful thinking,
> asserted with great  vigor, all the way into extinction.
> 
> We ignore established networking practise at the very real peril of
> the  technology we are trying to get used.

Are you arguing that IPv6 deployment is not underway ?  

Thierry.

Delivery-date: Mon, 28 Mar 2005 18:23:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Mon, 28 Mar 2005 13:22:52 -0500
From: "Bound, Jim" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "shim6" <[email-masked]>

> > >  2. Why is shim6 limited to IPv6?  What is it about the
> > >  problem space and/or the solution space that is required 
> to exclude IPv4?
> > >
> >  First because we have no chance of solving the IPv4 problem. 
> 
> Forgive me, but I do not see what it is about shim6 that 
> cannot work equally 
> well for IPv4.  That is really an underlying technical 
> question I am trying to 
> ask.

It has to do with implementation and time to market.  shims will have to
map to addresses and data structures for IPv6 and that is x amount of
work.  Adding IPv4 increases that work to deliver.

The point of this work has always been to focus on an IPv6 solution.

If the architecture and specs completed support IPv4 that is useful I
agree but our technical focus here is IPv6 and IPv6 architecture and
dynamics in implementation has characteristics that don't exist in IPv4.
For example if we want to pass shims between peers we can do that quite
nicely with IPv6 as Ext Hdr or DST option for IPv4 we have to do it
another way.  That is more work.

Thus the main concern is time-to-market for IPv6 multihoming from this
work not IPv4 and always has been the rules of engagement.

> 
> It is one thing to exclude IPv4 if the work somehow, 
> fundamentally, depends on 
> the distinctive characteristics of IPv6.  

I suggest it does as we define mechansims to make the shim work.

>It is another to 
> exclude it because 
> of an arbitrary preference.  IPv4 is the installed base.

It is also because that is the work focus we agreed upon.

> 
> 
> > >  3. What happens to shim6 if it must operate through a NAT?
> > >
> >  If this is for IPv6 the deployment efforts are trying to 
> eliminate NAT
> >  as majority view out of the IETF in the deployment community.
> 
> I am not arguing about the IETF religion against NATs, or 
> even about the 

Nor am I.

> legitimate feeling that NATs are messy and the IP 
> architectural world would be 
> better without them.

But this is aximatic.

> 
> My point is that NATs exist on a very large scale and they 
> seem to exist for a 
> variety of reasons. 

They exist for IPv4 they do not have to exist for IPv6 and they are
being avoided now in the IPv6 deployment stage.  Clearly there will be
isolated cases.
 
> 
> To require that IPv6 be used without NATs is to assert a 
> restriction on 
> current operational practice that is extremely risky, in terms of the 
> willingness of operations staff to concur.  Hence, it imposes 
> a very high 
> barrier to adoption, given the network operations models for 
> most IT staff and 
> home users.

This is why IPv6 WG deprecated NAT-PT spec we cannot propogate NAT in
good coscience.

> 
> In other words, we cannot make NATs go away simply because of 
> IETF opinion.  
> It would, therefore, be wise for an IETF effort either to be 
> NAT-neutral, when 
> possible, or to deal with their likely presence explicitly 
> and constructively.

I think NAT is orthogonal to the work for shim6 technically and this
discussion is moot. shim6 will not benefit or detract from NAT. In any
form technically.

> 
> 
> > >  While both outcomes are appealing, all
> > >  operational history to date suggests that those outcomes are,
> > >  at best, far
> > >  into the future, if they will occur at all.  (Predictions of
> > >  changes to the
> > >  installed base of widely-adopted services are almost 
> always wrong.)
> > >
> >  Don't agree.  IPv6 deployment is infrastructure stage now 
> and equipement
> >  purchases to support IPv6 are in process and transition 
> planning within
> 
> I hope you realize how much this language echoes OSI 
> predictions made long 
> ago.

That is invalid comparison, OSI was a completely new protoocol and IPv6
is an extension to the Internet model and Ipv6 is being deployed and
planned already far beyond anywhere OSI was ever done.  It is now a
requirement for implemementation in specific markets and vendors are
making money on IPv6 already which they did not with OSI.  

>  It was an interesting example of wishful thinking, 
> asserted with great 
> vigor, all the way into extinction.

Comparing OSI and IPv6 is like comparing apples and oranges. 

> 
> We ignore established networking practise at the very real 
> peril of the 
> technology we are trying to get used.

No one has done with the IPv6 deployment strategy at all.  IPv6 greatest
business and operational benefit is that it can restore the end-to-end
model of networking and security.  All I know realize we need to migrate
from NAT and do it wisely.

> 
> 
> > >  The danger of critical dependencies like these is that the
> > >  current work cannot
> > >  become widely useful unless and until those dependencies are
> > >  satisfied.
> > >
> >  I think our job is to define a solution.  That is what we do in the
> >  IETF. For example we defined neighbor discovery, an API, 
> updated routing
> >  protocols to support IPv6, and set of transition 
> mechanisms they are all
> >  being deployed.
> 
> When we define a "solution" that ignores established 
> operations practise or 
> fails to establish strong market need, then the solution 
> solves nothing, 
> because it fails to get adopted and used.

I agree and no one is proposing that and on the contrary the charter
does a good job of isolating the work and the eventual solution.

I think we are in agreement but coming at it from two different views.

/jim

Delivery-date: Mon, 28 Mar 2005 17:17:13 +0000
From: Dave Crocker <[email-masked]>
To: "Bound, Jim" <[email-masked]>, shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 28 Mar 2005 09:16:02 -0800
Subject: RE: Open question and Critical dependencies

> >  2. Why is shim6 limited to IPv6?  What is it about the
> >  problem space and/or the solution space that is required to exclude IPv4?
> >
>  First because we have no chance of solving the IPv4 problem. 

Forgive me, but I do not see what it is about shim6 that cannot work equally 
well for IPv4.  That is really an underlying technical question I am trying to 
ask.

It is one thing to exclude IPv4 if the work somehow, fundamentally, depends on 
the distinctive characteristics of IPv6.  It is another to exclude it because 
of an arbitrary preference.  IPv4 is the installed base.

> >  3. What happens to shim6 if it must operate through a NAT?
> >
>  If this is for IPv6 the deployment efforts are trying to eliminate NAT
>  as majority view out of the IETF in the deployment community.

I am not arguing about the IETF religion against NATs, or even about the 
legitimate feeling that NATs are messy and the IP architectural world would be 
better without them.

My point is that NATs exist on a very large scale and they seem to exist for a 
variety of reasons.  

To require that IPv6 be used without NATs is to assert a restriction on 
current operational practice that is extremely risky, in terms of the 
willingness of operations staff to concur.  Hence, it imposes a very high 
barrier to adoption, given the network operations models for most IT staff and 
home users.

In other words, we cannot make NATs go away simply because of IETF opinion.  
It would, therefore, be wise for an IETF effort either to be NAT-neutral, when 
possible, or to deal with their likely presence explicitly and constructively.

> >  While both outcomes are appealing, all
> >  operational history to date suggests that those outcomes are,
> >  at best, far
> >  into the future, if they will occur at all.  (Predictions of
> >  changes to the
> >  installed base of widely-adopted services are almost always wrong.)
> >
>  Don't agree.  IPv6 deployment is infrastructure stage now and equipement
>  purchases to support IPv6 are in process and transition planning within

I hope you realize how much this language echoes OSI predictions made long 
ago.  It was an interesting example of wishful thinking, asserted with great 
vigor, all the way into extinction.

We ignore established networking practise at the very real peril of the 
technology we are trying to get used.

> >  The danger of critical dependencies like these is that the
> >  current work cannot
> >  become widely useful unless and until those dependencies are
> >  satisfied.
> >
>  I think our job is to define a solution.  That is what we do in the
>  IETF. For example we defined neighbor discovery, an API, updated routing
>  protocols to support IPv6, and set of transition mechanisms they are all
>  being deployed.

When we define a "solution" that ignores established operations practise or 
fails to establish strong market need, then the solution solves nothing, 
because it fails to get adopted and used.

On Sun, 27 Mar 2005 21:06:12 +0200, Leif Johansson wrote:
> >  2. Why is shim6 limited to IPv6?  What is it about the problem space
> >  and/or
> >  the solution space that is required to exclude IPv4?
>
>  Because the WG is tasked with implementing a design from multi_6_ (my
>  highlights :-) and not from multi4?

In other words, the reason for excluding the entire installed base of IPv4 
users is because a previous working group excluded it?  

The word "tautology" comes to mind.

>  Isn't it reasonable to summarize the v4/v6 thread on this list as "if
>  we can make it work on v4 we will but it isn't a requirement" ?

Probably not, because a) it isn't in the charter, and b) my point was that 
shim6 should pay serious attention to current practise.  Treating IPv4 and 
NATs as if they do not (or, rather, will not) exist is not the way to do that.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Mon, 28 Mar 2005 17:12:37 +0000
Date: Mon, 28 Mar 2005 09:11:27 -0800
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: Jari Arkko <[email-masked]>, "Bound, Jim" <[email-masked]>, Thierry Ernst <[email-masked]>, shim6 <[email-masked]>
Subject: Re: proposed text for charter

Brian E Carpenter wrote:
> Well, I disagree. This may amount to asking for the
> impossible. We can properly require a shim6 implementation to
> co-exist with mobility implementations, but we cannot require it
> to operate simultaneously with them; that may turn out to be
> simply impossible. As I wrote a few days ago, it may be necessary
> to instruct shim6 to switch itelf off when some other functions
> are switched on.

While I don't have a problem with the charter not committing to solving 
this problem, I don't see it as being as hard as you think.

We have shim6, which says it will be transparent to what runs of top of 
it, be it TCP, UDP, ICMP, or anything else.

We have MIPv6, which is transparent to what runs on top of it the same way.

Thus both layering shim6 over mipv6, and layering mipv6 over shim6, 
should work in the sense that the protocol mechanisms continue to 
function. Whether either or both combinations provide a useful combined 
"service" is a different matter, but it seems to me that the shim6 
layered over mipv6 can be quite useful in the case of a mobile IPv6 node 
which has multiple home addresses, perhaps from independent home agents, 
where the shim6 overlay would could be used to create a system where a 
home agent (or the network in which the home agent resides) is not a 
single point of failure.

    Erik

Delivery-date: Mon, 28 Mar 2005 14:23:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Mon, 28 Mar 2005 09:19:38 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "Iljitsch van Beijnum" <[email-masked]>, "Dave Crocker" <[email-masked]>, "shim6" <[email-masked]>

Brian,

Well then that needs to be in the charter and may still be discussion
point. This is a new working group and not all have ever bought into the
shim at all but to work on it. Even the spec has research flavor.
Industry is not going to implement research even if the IETF specifies
it.

The way it works is if the application restarts ergo TCP RESTART, UDP
disconnect.

The shim should be isolated to the node to solve its multhoming problem.

Otherwise the shims must be passed and the address pairs are not used
and that is highly questionable at the end of the day the address pairs
should still be used for end-to-end communications and that must be part
of the ULID strategy.  Changing the address pairs say for TCP session is
a completely different problem for implementation and if we want to do
that too then we are really on the wrong path here and SCTP is clearly
the way to do that.

/jim 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Monday, March 28, 2005 9:09 AM
> To: Bound, Jim
> Cc: Iljitsch van Beijnum; Dave Crocker; shim6
> Subject: Re: Open question and Critical dependencies
> 
> Jim,
> 
> shim6 is a solution with state at both ends. I don't know
> how to make a solution with state at both ends work when
> there is only state at one end. This was very clear when
> multi6 recommended shim6 as the direction.
> 
>     Brian
> 
> Bound, Jim wrote:
> > both ends should not need to know about the shim to solve the MH
> > problem. if it the application restarts.
> > 
> > Are we saying in the charter the application does not have 
> to restart?
> > 
> > /jim 
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On 
> >>Behalf Of Brian E Carpenter
> >>Sent: Monday, March 28, 2005 6:20 AM
> >>To: Iljitsch van Beijnum
> >>Cc: Dave Crocker; shim6
> >>Subject: Re: Open question and Critical dependencies
> >>
> >>Iljitsch van Beijnum wrote:
> >>
> >>>On 27-mrt-05, at 20:21, Dave Crocker wrote:
> >>>
> >>>
> >>>>1. What does "This solution should work whether or not the 
> >>
> >>peer site 
> >>
> >>>>supports
> >>>>the shim6 protocol" mean in the draft charter and how can 
> >>
> >>it succeed?
> >>
> >>>
> >>>What Geoff wrote is:
> >>>
> >>>"Solutions for site exit router selection that works when 
> >>
> >>each ISP uses 
> >>
> >>>ingress filtering, i.e. when the chosen site exit needs to 
> >>
> >>be related to 
> >>
> >>>the source address chosen by the host. This solution should 
> >>
> >>work whether 
> >>
> >>>or not the peer site supports the shim6 protocol."
> >>>
> >>>I'm pretty sure "this solution" in this sentence refers to 
> >>
> >>site exit 
> >>
> >>>router selection, which is necessary to get around ingress 
> >>
> >>filtering by 
> >>
> >>>ISPs.
> >>
> >>And possibly also to the address selection mechanisms prior to
> >>exit router selection. Clearly, the double-ended stateful part of
> >>the shim cannot work when only one end knows about it.
> >>
> >>
> >>>A slight rewording would probably be a good idea.
> >>
> >>Yes
> >>
> >>
> >>>>2. Why is shim6 limited to IPv6?  What is it about the 
> >>
> >>problem space 
> >>
> >>>>and/or
> >>>>the solution space that is required to exclude IPv4?
> >>>
> >>>
> >>>There are many answers to this question.
> >>>
> >>>First of all, the multi6 wg was formed because the way 
> >>
> >>multihoming is 
> >>
> >>>done in IPv4 won't scale to the levels presumed necessary 
> >>
> >>in IPv6. So 
> >>
> >>>the problem is assumed to not exist in IPv4 as people can 
> >>
> >>get portable 
> >>
> >>>address space and announce it to multiple ISPs today. (Ok, 
> >>
> >>it doesn't 
> >>
> >>>scale in IPv4 either... But it seems to work for now.)
> >>>
> >>>Then there is the issue that with any multiaddress solution 
> >>
> >>you're going 
> >>
> >>>to burn IPv4 addresses at least twice as fast as by single 
> >>
> >>homing or 
> >>
> >>>PI/BGP multihoming, and we don't even have enough IPv4 
> >>
> >>addresses to give 
> >>
> >>>every person on the planet a single one.
> >>>
> >>>Also, IPv6 has some features that come in handy for solving 
> >>
> >>the problem. 
> >>
> >>>For instance, HBA or CGA which are proposed to secure the address 
> >>>agility, put cryptographic information in the bottom half 
> >>
> >>of the IPv6 
> >>
> >>>address, and there are / have been some ideas about using 
> >>
> >>the flow label.
> >>
> >>Exactly. IPv4 doesn't have the features we need to make 
> shim6 viable.
> >>
> >>
> >>>Last but not least, IPv4 is hampered with lots of ballast 
> >>
> >>in the form of 
> >>
> >>>overzealous firewalls, different kinds of NATs and old 
> >>
> >>implementations 
> >>
> >>>and all kinds of unwise assumptions that something as 
> >>
> >>radical as this 
> >>
> >>>stands a rather small chance of being deployable in the 
> >>
> >>current IPv4 
> >>
> >>>internet. (See ECN and path MTU discovery.) Presumably, 
> >>
> >>these issues 
> >>
> >>>won't be quite as bad in IPv6 because there is less old 
> >>
> >>crap and bad 
> >>
> >>>habits.
> >>>
> >>>
> >>>>3. What happens to shim6 if it must operate through a NAT?
> >>>
> >>>
> >>>Same as anything that must operate through a NAT: that 
> >>
> >>problem is either 
> >>
> >>>solved by the NAT builder or suffered by the NAT user.
> >>>
> >>>NAT in IPv6 is a very bad idea, both because NAT is a very 
> >>
> >>bad idea in 
> >>
> >>>and of itself, but also because NAT in IPv6 immediately 
> >>
> >>kills one of the 
> >>
> >>>main advantages of IPv6 and of course if you're going to 
> >>
> >>use NAT anyway, 
> >>
> >>>why bother adopting IPv6?
> >>
> >>If someone is foolish enough to install IPv6 NAT they will 
> be able to
> >>use that to support old-fashioned NAT-based multihoming. We started
> >>multi6, and we are continuing shim6, precisely as one of 
> the main ways
> >>to make NAT unnecessary. So actually, we simply don't care if shim6
> >>fails through NAT.
> >>
> >>
> >>>>Items 2 & 3 establish critical dependencies on the 
> >>
> >>wide-scale adoption 
> >>
> >>>>of IPv6
> >>>>and the elimination of NATs.
> >>>
> >>>
> >>>Since the former implies the latter (at least right now, 
> >>
> >>but hopefully 
> >>
> >>>also for time to come) and for the short-to-medium term 
> there is no 
> >>>multihoming problem in IPv4, this doesn't pose a problem. 
> >>
> >>(Other than 
> >>
> >>>the possibility that we're wasting our time, which is a risk that 
> >>>everyone will have to weigh for themselves.)
> >>
> >>Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
> >>it will all have been a big waste of time. There's no news there.
> >>
> >>    Brian
> >>
> >>
> >>
> > 
> > 
> 
> 

Delivery-date: Mon, 28 Mar 2005 14:09:30 +0000
Date: Mon, 28 Mar 2005 16:09:00 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Bound, Jim" <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, Dave Crocker <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Jim,

shim6 is a solution with state at both ends. I don't know
how to make a solution with state at both ends work when
there is only state at one end. This was very clear when
multi6 recommended shim6 as the direction.

    Brian

Bound, Jim wrote:
> both ends should not need to know about the shim to solve the MH
> problem. if it the application restarts.
> 
> Are we saying in the charter the application does not have to restart?
> 
> /jim 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Brian E Carpenter
>>Sent: Monday, March 28, 2005 6:20 AM
>>To: Iljitsch van Beijnum
>>Cc: Dave Crocker; shim6
>>Subject: Re: Open question and Critical dependencies
>>
>>Iljitsch van Beijnum wrote:
>>
>>>On 27-mrt-05, at 20:21, Dave Crocker wrote:
>>>
>>>
>>>>1. What does "This solution should work whether or not the 
>>
>>peer site 
>>
>>>>supports
>>>>the shim6 protocol" mean in the draft charter and how can 
>>
>>it succeed?
>>
>>>
>>>What Geoff wrote is:
>>>
>>>"Solutions for site exit router selection that works when 
>>
>>each ISP uses 
>>
>>>ingress filtering, i.e. when the chosen site exit needs to 
>>
>>be related to 
>>
>>>the source address chosen by the host. This solution should 
>>
>>work whether 
>>
>>>or not the peer site supports the shim6 protocol."
>>>
>>>I'm pretty sure "this solution" in this sentence refers to 
>>
>>site exit 
>>
>>>router selection, which is necessary to get around ingress 
>>
>>filtering by 
>>
>>>ISPs.
>>
>>And possibly also to the address selection mechanisms prior to
>>exit router selection. Clearly, the double-ended stateful part of
>>the shim cannot work when only one end knows about it.
>>
>>
>>>A slight rewording would probably be a good idea.
>>
>>Yes
>>
>>
>>>>2. Why is shim6 limited to IPv6?  What is it about the 
>>
>>problem space 
>>
>>>>and/or
>>>>the solution space that is required to exclude IPv4?
>>>
>>>
>>>There are many answers to this question.
>>>
>>>First of all, the multi6 wg was formed because the way 
>>
>>multihoming is 
>>
>>>done in IPv4 won't scale to the levels presumed necessary 
>>
>>in IPv6. So 
>>
>>>the problem is assumed to not exist in IPv4 as people can 
>>
>>get portable 
>>
>>>address space and announce it to multiple ISPs today. (Ok, 
>>
>>it doesn't 
>>
>>>scale in IPv4 either... But it seems to work for now.)
>>>
>>>Then there is the issue that with any multiaddress solution 
>>
>>you're going 
>>
>>>to burn IPv4 addresses at least twice as fast as by single 
>>
>>homing or 
>>
>>>PI/BGP multihoming, and we don't even have enough IPv4 
>>
>>addresses to give 
>>
>>>every person on the planet a single one.
>>>
>>>Also, IPv6 has some features that come in handy for solving 
>>
>>the problem. 
>>
>>>For instance, HBA or CGA which are proposed to secure the address 
>>>agility, put cryptographic information in the bottom half 
>>
>>of the IPv6 
>>
>>>address, and there are / have been some ideas about using 
>>
>>the flow label.
>>
>>Exactly. IPv4 doesn't have the features we need to make shim6 viable.
>>
>>
>>>Last but not least, IPv4 is hampered with lots of ballast 
>>
>>in the form of 
>>
>>>overzealous firewalls, different kinds of NATs and old 
>>
>>implementations 
>>
>>>and all kinds of unwise assumptions that something as 
>>
>>radical as this 
>>
>>>stands a rather small chance of being deployable in the 
>>
>>current IPv4 
>>
>>>internet. (See ECN and path MTU discovery.) Presumably, 
>>
>>these issues 
>>
>>>won't be quite as bad in IPv6 because there is less old 
>>
>>crap and bad 
>>
>>>habits.
>>>
>>>
>>>>3. What happens to shim6 if it must operate through a NAT?
>>>
>>>
>>>Same as anything that must operate through a NAT: that 
>>
>>problem is either 
>>
>>>solved by the NAT builder or suffered by the NAT user.
>>>
>>>NAT in IPv6 is a very bad idea, both because NAT is a very 
>>
>>bad idea in 
>>
>>>and of itself, but also because NAT in IPv6 immediately 
>>
>>kills one of the 
>>
>>>main advantages of IPv6 and of course if you're going to 
>>
>>use NAT anyway, 
>>
>>>why bother adopting IPv6?
>>
>>If someone is foolish enough to install IPv6 NAT they will be able to
>>use that to support old-fashioned NAT-based multihoming. We started
>>multi6, and we are continuing shim6, precisely as one of the main ways
>>to make NAT unnecessary. So actually, we simply don't care if shim6
>>fails through NAT.
>>
>>
>>>>Items 2 & 3 establish critical dependencies on the 
>>
>>wide-scale adoption 
>>
>>>>of IPv6
>>>>and the elimination of NATs.
>>>
>>>
>>>Since the former implies the latter (at least right now, 
>>
>>but hopefully 
>>
>>>also for time to come) and for the short-to-medium term there is no 
>>>multihoming problem in IPv4, this doesn't pose a problem. 
>>
>>(Other than 
>>
>>>the possibility that we're wasting our time, which is a risk that 
>>>everyone will have to weigh for themselves.)
>>
>>Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
>>it will all have been a big waste of time. There's no news there.
>>
>>    Brian
>>
>>
>>
> 
> 

Delivery-date: Mon, 28 Mar 2005 13:48:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Mon, 28 Mar 2005 08:48:32 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>, "shim6" <[email-masked]>

both ends should not need to know about the shim to solve the MH
problem. if it the application restarts.

Are we saying in the charter the application does not have to restart?

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Monday, March 28, 2005 6:20 AM
> To: Iljitsch van Beijnum
> Cc: Dave Crocker; shim6
> Subject: Re: Open question and Critical dependencies
> 
> Iljitsch van Beijnum wrote:
> > On 27-mrt-05, at 20:21, Dave Crocker wrote:
> > 
> >> 1. What does "This solution should work whether or not the 
> peer site 
> >> supports
> >> the shim6 protocol" mean in the draft charter and how can 
> it succeed?
> > 
> > 
> > What Geoff wrote is:
> > 
> > "Solutions for site exit router selection that works when 
> each ISP uses 
> > ingress filtering, i.e. when the chosen site exit needs to 
> be related to 
> > the source address chosen by the host. This solution should 
> work whether 
> > or not the peer site supports the shim6 protocol."
> > 
> > I'm pretty sure "this solution" in this sentence refers to 
> site exit 
> > router selection, which is necessary to get around ingress 
> filtering by 
> > ISPs.
> 
> And possibly also to the address selection mechanisms prior to
> exit router selection. Clearly, the double-ended stateful part of
> the shim cannot work when only one end knows about it.
> 
> > 
> > A slight rewording would probably be a good idea.
> 
> Yes
> 
> > 
> >> 2. Why is shim6 limited to IPv6?  What is it about the 
> problem space 
> >> and/or
> >> the solution space that is required to exclude IPv4?
> > 
> > 
> > There are many answers to this question.
> > 
> > First of all, the multi6 wg was formed because the way 
> multihoming is 
> > done in IPv4 won't scale to the levels presumed necessary 
> in IPv6. So 
> > the problem is assumed to not exist in IPv4 as people can 
> get portable 
> > address space and announce it to multiple ISPs today. (Ok, 
> it doesn't 
> > scale in IPv4 either... But it seems to work for now.)
> > 
> > Then there is the issue that with any multiaddress solution 
> you're going 
> > to burn IPv4 addresses at least twice as fast as by single 
> homing or 
> > PI/BGP multihoming, and we don't even have enough IPv4 
> addresses to give 
> > every person on the planet a single one.
> > 
> > Also, IPv6 has some features that come in handy for solving 
> the problem. 
> > For instance, HBA or CGA which are proposed to secure the address 
> > agility, put cryptographic information in the bottom half 
> of the IPv6 
> > address, and there are / have been some ideas about using 
> the flow label.
> 
> Exactly. IPv4 doesn't have the features we need to make shim6 viable.
> 
> > 
> > Last but not least, IPv4 is hampered with lots of ballast 
> in the form of 
> > overzealous firewalls, different kinds of NATs and old 
> implementations 
> > and all kinds of unwise assumptions that something as 
> radical as this 
> > stands a rather small chance of being deployable in the 
> current IPv4 
> > internet. (See ECN and path MTU discovery.) Presumably, 
> these issues 
> > won't be quite as bad in IPv6 because there is less old 
> crap and bad 
> > habits.
> > 
> >> 3. What happens to shim6 if it must operate through a NAT?
> > 
> > 
> > Same as anything that must operate through a NAT: that 
> problem is either 
> > solved by the NAT builder or suffered by the NAT user.
> > 
> > NAT in IPv6 is a very bad idea, both because NAT is a very 
> bad idea in 
> > and of itself, but also because NAT in IPv6 immediately 
> kills one of the 
> > main advantages of IPv6 and of course if you're going to 
> use NAT anyway, 
> > why bother adopting IPv6?
> 
> If someone is foolish enough to install IPv6 NAT they will be able to
> use that to support old-fashioned NAT-based multihoming. We started
> multi6, and we are continuing shim6, precisely as one of the main ways
> to make NAT unnecessary. So actually, we simply don't care if shim6
> fails through NAT.
> 
> > 
> >> Items 2 & 3 establish critical dependencies on the 
> wide-scale adoption 
> >> of IPv6
> >> and the elimination of NATs.
> > 
> > 
> > Since the former implies the latter (at least right now, 
> but hopefully 
> > also for time to come) and for the short-to-medium term there is no 
> > multihoming problem in IPv4, this doesn't pose a problem. 
> (Other than 
> > the possibility that we're wasting our time, which is a risk that 
> > everyone will have to weigh for themselves.)
> 
> Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
> it will all have been a big waste of time. There's no news there.
> 
>     Brian
> 
> 
> 

Delivery-date: Mon, 28 Mar 2005 13:42:20 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Mon, 28 Mar 2005 08:41:46 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "Jari Arkko" <[email-masked]>
Cc: "Thierry Ernst" <[email-masked]>, "shim6" <[email-masked]>

If that is the case then shim6 is a hack and that is not cool.  Hacks
from the IETF is the last thing we need in the industry we have enough
of our own home grown hacks. To do what is proposed is proper
engineering for any effort.
/jim 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Monday, March 28, 2005 6:13 AM
> To: Jari Arkko
> Cc: Bound, Jim; Thierry Ernst; shim6
> Subject: Re: proposed text for charter
> 
> Well, I disagree. This may amount to asking for the
> impossible. We can properly require a shim6 implementation to
> co-exist with mobility implementations, but we cannot require it
> to operate simultaneously with them; that may turn out to be
> simply impossible. As I wrote a few days ago, it may be necessary
> to instruct shim6 to switch itelf off when some other functions
> are switched on.
> 
>     Brian
> 
> Jari Arkko wrote:
> > Ok for me too. --Jari
> > 
> > Bound, Jim wrote:
> > 
> >> I agree ....
> >> /jim
> >>  
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> >>> Thierry Ernst
> >>> Sent: Sunday, March 27, 2005 11:01 PM
> >>> To: shim6
> >>> Subject: Re: proposed text for charter
> >>>
> >>>
> >>>
> >>> About the following item in the charter:
> >>> o  The solution must not cause problems for mobility. That is, it
> >>>    should be possible to continue using Mobile IPv6 even 
> when using
> >>>    shim6 simultaneously. However, any optimizations or advanced
> >>>    configurations are out of scope for shim6.
> >>>
> >>> I would suggest to write "should be possile to continue 
> using mobility
> >>> support protocols such as Mobile IPv6 land NEMO Basic Support"
> >>>
> >>> An additional item such as the following one would be useful:
> >>>
> >>> - The WG will ensure that various mechanisms defined 
> within other IETF
> >>> WGs will continue to work when using shmi6 
> simultaneously.  To achieve
> >>> this, the Shim6 WG will interact with other WGs when 
> needed, and may
> >>> place requirements on the protocols developed by those WGs.
> >>>
> >>>
> >>> Thierry.
> >>>
> >>>
> >>>   
> >>
> >>
> >>
> >>
> >>  
> >>
> > 
> > 
> 
> 

Delivery-date: Mon, 28 Mar 2005 11:20:26 +0000
Date: Mon, 28 Mar 2005 13:20:21 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Dave Crocker <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Iljitsch van Beijnum wrote:
> On 27-mrt-05, at 20:21, Dave Crocker wrote:
> 
>> 1. What does "This solution should work whether or not the peer site 
>> supports
>> the shim6 protocol" mean in the draft charter and how can it succeed?
> 
> 
> What Geoff wrote is:
> 
> "Solutions for site exit router selection that works when each ISP uses 
> ingress filtering, i.e. when the chosen site exit needs to be related to 
> the source address chosen by the host. This solution should work whether 
> or not the peer site supports the shim6 protocol."
> 
> I'm pretty sure "this solution" in this sentence refers to site exit 
> router selection, which is necessary to get around ingress filtering by 
> ISPs.

And possibly also to the address selection mechanisms prior to
exit router selection. Clearly, the double-ended stateful part of
the shim cannot work when only one end knows about it.

> 
> A slight rewording would probably be a good idea.

Yes

> 
>> 2. Why is shim6 limited to IPv6?  What is it about the problem space 
>> and/or
>> the solution space that is required to exclude IPv4?
> 
> 
> There are many answers to this question.
> 
> First of all, the multi6 wg was formed because the way multihoming is 
> done in IPv4 won't scale to the levels presumed necessary in IPv6. So 
> the problem is assumed to not exist in IPv4 as people can get portable 
> address space and announce it to multiple ISPs today. (Ok, it doesn't 
> scale in IPv4 either... But it seems to work for now.)
> 
> Then there is the issue that with any multiaddress solution you're going 
> to burn IPv4 addresses at least twice as fast as by single homing or 
> PI/BGP multihoming, and we don't even have enough IPv4 addresses to give 
> every person on the planet a single one.
> 
> Also, IPv6 has some features that come in handy for solving the problem. 
> For instance, HBA or CGA which are proposed to secure the address 
> agility, put cryptographic information in the bottom half of the IPv6 
> address, and there are / have been some ideas about using the flow label.

Exactly. IPv4 doesn't have the features we need to make shim6 viable.

> 
> Last but not least, IPv4 is hampered with lots of ballast in the form of 
> overzealous firewalls, different kinds of NATs and old implementations 
> and all kinds of unwise assumptions that something as radical as this 
> stands a rather small chance of being deployable in the current IPv4 
> internet. (See ECN and path MTU discovery.) Presumably, these issues 
> won't be quite as bad in IPv6 because there is less old crap and bad 
> habits.
> 
>> 3. What happens to shim6 if it must operate through a NAT?
> 
> 
> Same as anything that must operate through a NAT: that problem is either 
> solved by the NAT builder or suffered by the NAT user.
> 
> NAT in IPv6 is a very bad idea, both because NAT is a very bad idea in 
> and of itself, but also because NAT in IPv6 immediately kills one of the 
> main advantages of IPv6 and of course if you're going to use NAT anyway, 
> why bother adopting IPv6?

If someone is foolish enough to install IPv6 NAT they will be able to
use that to support old-fashioned NAT-based multihoming. We started
multi6, and we are continuing shim6, precisely as one of the main ways
to make NAT unnecessary. So actually, we simply don't care if shim6
fails through NAT.

> 
>> Items 2 & 3 establish critical dependencies on the wide-scale adoption 
>> of IPv6
>> and the elimination of NATs.
> 
> 
> Since the former implies the latter (at least right now, but hopefully 
> also for time to come) and for the short-to-medium term there is no 
> multihoming problem in IPv4, this doesn't pose a problem. (Other than 
> the possibility that we're wasting our time, which is a risk that 
> everyone will have to weigh for themselves.)

Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
it will all have been a big waste of time. There's no news there.

    Brian

Delivery-date: Mon, 28 Mar 2005 11:13:39 +0000
Date: Mon, 28 Mar 2005 13:12:30 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Jari Arkko <[email-masked]>
CC: "Bound, Jim" <[email-masked]>, Thierry Ernst <[email-masked]>, shim6 <[email-masked]>
Subject: Re: proposed text for charter

Well, I disagree. This may amount to asking for the
impossible. We can properly require a shim6 implementation to
co-exist with mobility implementations, but we cannot require it
to operate simultaneously with them; that may turn out to be
simply impossible. As I wrote a few days ago, it may be necessary
to instruct shim6 to switch itelf off when some other functions
are switched on.

    Brian

Jari Arkko wrote:
> Ok for me too. --Jari
> 
> Bound, Jim wrote:
> 
>> I agree ....
>> /jim
>>  
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>>> Thierry Ernst
>>> Sent: Sunday, March 27, 2005 11:01 PM
>>> To: shim6
>>> Subject: Re: proposed text for charter
>>>
>>>
>>>
>>> About the following item in the charter:
>>> o  The solution must not cause problems for mobility. That is, it
>>>    should be possible to continue using Mobile IPv6 even when using
>>>    shim6 simultaneously. However, any optimizations or advanced
>>>    configurations are out of scope for shim6.
>>>
>>> I would suggest to write "should be possile to continue using mobility
>>> support protocols such as Mobile IPv6 land NEMO Basic Support"
>>>
>>> An additional item such as the following one would be useful:
>>>
>>> - The WG will ensure that various mechanisms defined within other IETF
>>> WGs will continue to work when using shmi6 simultaneously.  To achieve
>>> this, the Shim6 WG will interact with other WGs when needed, and may
>>> place requirements on the protocols developed by those WGs.
>>>
>>>
>>> Thierry.
>>>
>>>
>>>   
>>
>>
>>
>>
>>  
>>
> 
> 

Delivery-date: Mon, 28 Mar 2005 05:44:04 +0000
Date: Mon, 28 Mar 2005 14:48:15 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

Sorry, this mail has nothing to do with Shim6, but let me clarify that
people in different sides of the world have different perceptions of
the needs of (future) applications.

I don't know what "bell-heads" means and I don't agree with this
perception of the application needs. The applications mentioned below
are applications we use today, what I'm talking about are the
applications we would like to have tomorrow, provided network mechanisms
have been designed in a way that will allow them (I would call this
"planning"). A bunch of them would need L3 mobility, and would be
assuming L4 stability. Session restablishment would be considered as a
bug, not a feature, by next generation users.

We may not live in the same side of the planet which may explain
differences in our respective point of view; both are worth to be
considered by enhanced protocols.

Thierry

 On Wed, 23 Mar 2005 11:21:19 +0100
Iljitsch van Beijnum <[email-masked]> wrote:

> On 23-mrt-05, at 3:07, Thierry Ernst wrote:
> 
> >> You have to drill a bit deeper as mobile phones aren't an
> >application > so it's impossible to determine whether they need layer
> >4 stability on >  top of layer 3 mobility.
> 
> > I'm afraid I don't understand the comment, but if it's what I think,
> > I would answer that to me it's pretty clear they need layer 4
> > stability.
> 
> No it's not. The only application I would really want this for is 
> remote login, but with the right tools reestablishing such a session
> is  trivial.
> 
> It would be nice to keep a/v streams running when switching 
> infrastructures, but congestion issues make this very problematic.
> 
> I think someone else mentioned one other application that could use 
> layer 4 stability on top of layer 3 changes, but I can't find this. 
> Stuff like web and file transfer don't need this capability, and in 
> mail only downloading large attachments would be helped by it, but 
> changing the pop/imap protocols can address this just as easily.
> 
> I suspect that the "need" for mobility is 99% driven by bell-heads who
>  still think in terms of services that must provide a seamless 
> experience to the user. Guess what: the "user" is a big company 
> building complex software, and if they can handle stuff like this 
> themselves (for instance, by restarting file transfers after an 
> interruption) they'll be happy to do so.
> 
> > I think that the discussion is about putting the right thing in the
> > charter, so I don't think it's coming at the wrong moment - rather
> > at the right time, before the WG is approved.
> 
> My answer remains the same: "not now". What could go into the charter 
> about mobility that would be helpful at this point in time? (And "we 
> need mobility, you guys figure it out!" doesn't qualify as "helpful".)
>  The wg can always recharter after finishing some specified amount of 
> work.

Delivery-date: Mon, 28 Mar 2005 04:50:49 +0000
Date: Mon, 28 Mar 2005 07:50:43 +0300
From: Jari Arkko <[email-masked]>
To: "Bound, Jim" <[email-masked]>
Cc: Thierry Ernst <[email-masked]>, shim6 <[email-masked]>
Subject: Re: proposed text for charter

Ok for me too. --Jari

Bound, Jim wrote:

>I agree ....
>/jim 
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Thierry Ernst
>>Sent: Sunday, March 27, 2005 11:01 PM
>>To: shim6
>>Subject: Re: proposed text for charter
>>
>>
>>
>>About the following item in the charter:
>>o  The solution must not cause problems for mobility. That is, it
>>    should be possible to continue using Mobile IPv6 even when using
>>    shim6 simultaneously. However, any optimizations or advanced
>>    configurations are out of scope for shim6.
>>
>>I would suggest to write "should be possile to continue using mobility
>>support protocols such as Mobile IPv6 land NEMO Basic Support"
>>
>>An additional item such as the following one would be useful:
>>
>>- The WG will ensure that various mechanisms defined within other IETF
>>WGs will continue to work when using shmi6 simultaneously.  To achieve
>>this, the Shim6 WG will interact with other WGs when needed, and may
>>place requirements on the protocols developed by those WGs.
>>
>>
>>Thierry.
>>
>>
>>    
>>
>
>
>
>  
>

Delivery-date: Mon, 28 Mar 2005 04:35:33 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Sun, 27 Mar 2005 23:35:09 -0500
From: "Bound, Jim" <[email-masked]>
To: "Thierry Ernst" <[email-masked]>, "shim6" <[email-masked]>

I agree ....
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thierry Ernst
> Sent: Sunday, March 27, 2005 11:01 PM
> To: shim6
> Subject: Re: proposed text for charter
> 
> 
> 
> About the following item in the charter:
> o  The solution must not cause problems for mobility. That is, it
>     should be possible to continue using Mobile IPv6 even when using
>     shim6 simultaneously. However, any optimizations or advanced
>     configurations are out of scope for shim6.
> 
> I would suggest to write "should be possile to continue using mobility
> support protocols such as Mobile IPv6 land NEMO Basic Support"
> 
> An additional item such as the following one would be useful:
> 
> - The WG will ensure that various mechanisms defined within other IETF
> WGs will continue to work when using shmi6 simultaneously.  To achieve
> this, the Shim6 WG will interact with other WGs when needed, and may
> place requirements on the protocols developed by those WGs.
> 
> 
> Thierry.
> 
> 

Delivery-date: Mon, 28 Mar 2005 03:56:29 +0000
Date: Mon, 28 Mar 2005 13:00:40 +0900
From: Thierry Ernst <[email-masked]>
To: shim6 <[email-masked]>
Subject: Re: proposed text for charter
Organization: Keio University

About the following item in the charter:
o  The solution must not cause problems for mobility. That is, it
    should be possible to continue using Mobile IPv6 even when using
    shim6 simultaneously. However, any optimizations or advanced
    configurations are out of scope for shim6.

I would suggest to write "should be possile to continue using mobility
support protocols such as Mobile IPv6 land NEMO Basic Support"

An additional item such as the following one would be useful:

- The WG will ensure that various mechanisms defined within other IETF
WGs will continue to work when using shmi6 simultaneously.  To achieve
this, the Shim6 WG will interact with other WGs when needed, and may
place requirements on the protocols developed by those WGs.

Thierry.

Delivery-date: Mon, 28 Mar 2005 00:19:08 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Sun, 27 Mar 2005 19:18:32 -0500
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6" <[email-masked]>

> > In addition 3493 permits a
> > means to program with IPv4 and IPv6 in address family 
> indepdent manner.
> 
> You said it: IPv4 and IPv6. What about IPs v7 - 15 ?

If that should happen the new Address Family independent semantics of
3493 will support new families as it will new data structures if we do
require ULIDs for the shim6 work to relay something relative to this
list on this topic.

Note this was one reason 3493 was supported as IEEE POSIX API extension
because of getaddrinfo and getnameinfo updates to do exactly what you
believe important. The actual standard is from the IEEE via the Open
Group the IETF work is simply informational.

> 
> Also, I assume you're talking about IPv4-mapped addresses. I think 
> those are great but unfortunately there are others who disagree and 
> failed to implement them, which makes writing IP version agnostic 
> impossible on some systems and therefore non-portable on all systems.
> 
> But I suggest we agree to disagree, at least on this list.  :-)

That is fine but updates have been done and all implementations do now
support IPv4mapped addresses and that subject has reached consensus on
the IPv6 WG list.  We should not go there here at all.  

Not sure where we don't agree 3493 can be used to support the absolute
value of being agnostic with regards to Address Family, Address Form,
and should we use ULID version 1 and have to update it layer it will
support a different ULID version 2 later. Implementations would do this
by adding libraries for such functions and the kernel support to support
those functions.  If we were to implement Erik Normark's draft this is
how it could be done and be transparent to applications again to make
this mail relative to this IETF list.

/jim
> 
> 

Delivery-date: Sun, 27 Mar 2005 20:37:12 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Sun, 27 Mar 2005 22:36:57 +0200
To: Dave Crocker <[email-masked]>

On 27-mrt-05, at 20:21, Dave Crocker wrote:

> 1. What does "This solution should work whether or not the peer site 
> supports
> the shim6 protocol" mean in the draft charter and how can it succeed?

What Geoff wrote is:

"Solutions for site exit router selection that works when each ISP uses 
ingress filtering, i.e. when the chosen site exit needs to be related 
to the source address chosen by the host. This solution should work 
whether or not the peer site supports the shim6 protocol."

I'm pretty sure "this solution" in this sentence refers to site exit 
router selection, which is necessary to get around ingress filtering by 
ISPs.

A slight rewording would probably be a good idea.

> 2. Why is shim6 limited to IPv6?  What is it about the problem space 
> and/or
> the solution space that is required to exclude IPv4?

There are many answers to this question.

First of all, the multi6 wg was formed because the way multihoming is 
done in IPv4 won't scale to the levels presumed necessary in IPv6. So 
the problem is assumed to not exist in IPv4 as people can get portable 
address space and announce it to multiple ISPs today. (Ok, it doesn't 
scale in IPv4 either... But it seems to work for now.)

Then there is the issue that with any multiaddress solution you're 
going to burn IPv4 addresses at least twice as fast as by single homing 
or PI/BGP multihoming, and we don't even have enough IPv4 addresses to 
give every person on the planet a single one.

Also, IPv6 has some features that come in handy for solving the 
problem. For instance, HBA or CGA which are proposed to secure the 
address agility, put cryptographic information in the bottom half of 
the IPv6 address, and there are / have been some ideas about using the 
flow label.

Last but not least, IPv4 is hampered with lots of ballast in the form 
of overzealous firewalls, different kinds of NATs and old 
implementations and all kinds of unwise assumptions that something as 
radical as this stands a rather small chance of being deployable in the 
current IPv4 internet. (See ECN and path MTU discovery.) Presumably, 
these issues won't be quite as bad in IPv6 because there is less old 
crap and bad habits.

> 3. What happens to shim6 if it must operate through a NAT?

Same as anything that must operate through a NAT: that problem is 
either solved by the NAT builder or suffered by the NAT user.

NAT in IPv6 is a very bad idea, both because NAT is a very bad idea in 
and of itself, but also because NAT in IPv6 immediately kills one of 
the main advantages of IPv6 and of course if you're going to use NAT 
anyway, why bother adopting IPv6?

> Items 2 & 3 establish critical dependencies on the wide-scale adoption 
> of IPv6
> and the elimination of NATs.

Since the former implies the latter (at least right now, but hopefully 
also for time to come) and for the short-to-medium term there is no 
multihoming problem in IPv4, this doesn't pose a problem. (Other than 
the possibility that we're wasting our time, which is a risk that 
everyone will have to weigh for themselves.)

Delivery-date: Sun, 27 Mar 2005 20:11:40 +0000
Cc: "shim6" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Sun, 27 Mar 2005 22:11:07 +0200
To: "Bound, Jim" <[email-masked]>

On 27-mrt-05, at 18:56, Bound, Jim wrote:

> Your completely missing the point of 3493 and some of the most 
> brilliant
> and serious network programmers in the IETF worked on this API for
> years.

Hm, if success depends on years of work by the most brilliant people 
around, this indicates that there is a problem somewhere...

> In addition 3493 permits a
> means to program with IPv4 and IPv6 in address family indepdent manner.

You said it: IPv4 and IPv6. What about IPs v7 - 15 ?

Also, I assume you're talking about IPv4-mapped addresses. I think 
those are great but unfortunately there are others who disagree and 
failed to implement them, which makes writing IP version agnostic 
impossible on some systems and therefore non-portable on all systems.

But I suggest we agree to disagree, at least on this list.  :-)

Delivery-date: Sun, 27 Mar 2005 19:06:21 +0000
Date: Sun, 27 Mar 2005 21:06:12 +0200
From: Leif Johansson <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies

Dave Crocker wrote:
> Folks,
> 
> The current draft charter prompts some basic questions:
> 
> 
> 1. What does "This solution should work whether or not the peer site supports 
> the shim6 protocol" mean in the draft charter and how can it succeed?
> 

Doesn't it mean to say "communication will be possible wo shim6 at both
ends?" or something to that effect?

> 
> 2. Why is shim6 limited to IPv6?  What is it about the problem space and/or 
> the solution space that is required to exclude IPv4?
> 

Because the WG is tasked with implementing a design from multi_6_ (my
highlights :-) and not from multi4?

Isn't it reasonable to summarize the v4/v6 thread on this list as "if
we can make it work on v4 we will but it isn't a requirement" ?

	Cheers Leif

Delivery-date: Sun, 27 Mar 2005 18:58:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Open question and Critical dependencies
Date: Sun, 27 Mar 2005 13:57:42 -0500
From: "Bound, Jim" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "shim6" <[email-masked]>

> The current draft charter prompts some basic questions:
> 
> 
> 1. What does "This solution should work whether or not the 
> peer site supports 
> the shim6 protocol" mean in the draft charter and how can it succeed?

This is important question.  My interpretation is if two nodes are
communiczting peer-to-peer nodes A and B.  Where A supports the shim but
B does not.  That A should be able to use the shim implementation if B
does not.  This is a response not that I support this shim effort yet at
this time for impelementation in products.

> 
> 
> 2. Why is shim6 limited to IPv6?  What is it about the 
> problem space and/or 
> the solution space that is required to exclude IPv4?

First because we have no chance of solving the IPv4 problem. Second to
limit the scope of work. Third because the most serious issues and cause
for this work is that IPv6 could cause major per host route address
space invasion when IPv6 supports end-to-end and mobility in the market
and walled gardens go down via 3G.  In addition it will make
implementation of a solution more expedient and if it works well then a
backport discussion of IPv4 can be discussed.

> 
> 
> 3. What happens to shim6 if it must operate through a NAT?

If this is for IPv6 the deployment efforts are trying to eliminate NAT
as majority view out of the IETF in the deployment community.  The one
case that will exacerbate this issue is the consumer market from the
home user who will be behind a NAT for some time where the dual IP layer
approaches will not work through a current NAT until those boxes support
protocol ID 41 (e.g. Linksys, Netgear).

But if shim6 or SCTP be were used with ULIDs for identification that
should be transparent to NAT which is an edge issue and NAT would be
dealing with IPv6 addresses not ULIDs.

> 
> 
> Items 2 & 3 establish critical dependencies on the wide-scale 
> adoption of IPv6 
> and the elimination of NATs.

I would suggest that also that NAT boxex permit v6-in-v4 and v4-in-v6
tunneling, and NAT would continue for now for IPv4, but not necessarily
for IPv6.  Thus there is a path where NAT exists for IPv4 and a
transition from NAT view with IPv6.

>  While both outcomes are appealing, all 
> operational history to date suggests that those outcomes are, 
> at best, far 
> into the future, if they will occur at all.  (Predictions of 
> changes to the 
> installed base of widely-adopted services are almost always wrong.)

Don't agree.  IPv6 deployment is infrastructure stage now and equipement
purchases to support IPv6 are in process and transition planning within
most ISPs and some large Enterprises, and the 3G, GSMA, etc. greenfield
providers.  So I  think we are in better shape than stated above and
several network pilots in existence today world wide are demonstrating
what I say above is in fact happening.  IPv6 for infrastructure
deployment and planning is in process and further along than many would
realize.

> 
> The danger of critical dependencies like these is that the 
> current work cannot 
> become widely useful unless and until those dependencies are 
> satisfied.

I think our job is to define a solution.  That is what we do in the
IETF. For example we defined neighbor discovery, an API, updated routing
protocols to support IPv6, and set of transition mechanisms they are all
being deployed.  

We need to define a technical solution in the IETF now for multihoming
for IPv6 the vendors and market will define how it is deployed and used.

Clearly we want to think of use and operations, but we should base our
work on trying to guess deployment or the market in this working group
or the IETF we simply are not good at that at all.

> Hence, the current charter guarantees that the shim6 work 
> will never be widely 
> useful, if IPv6 does not gain wide adoption OR if it must 
> operate through 
> NATs.

I emphatcially disagree witht the assumption to stop this work.  If one
does not beleive IPv6 will be widely deployed then I would suggest one
should not be working on this list and group and the charter to work on
Ipv6 has been here since the beginning and changing it is inappropriate
at this time.

> 
> And please note that I said "or" and not "and".  Hence, the 
> probabilities of 
> adoption barriers are multiplicative, ie, essentially 
> exponentially worse.

I don't agree.

/jim

> 
> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
> 
> 

Delivery-date: Sun, 27 Mar 2005 18:22:34 +0000
From: Dave Crocker <[email-masked]>
To: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sun, 27 Mar 2005 10:21:09 -0800
Subject: Open question and Critical dependencies

Folks,

The current draft charter prompts some basic questions:

1. What does "This solution should work whether or not the peer site supports 
the shim6 protocol" mean in the draft charter and how can it succeed?

2. Why is shim6 limited to IPv6?  What is it about the problem space and/or 
the solution space that is required to exclude IPv4?

3. What happens to shim6 if it must operate through a NAT?

Items 2 & 3 establish critical dependencies on the wide-scale adoption of IPv6 
and the elimination of NATs.  While both outcomes are appealing, all 
operational history to date suggests that those outcomes are, at best, far 
into the future, if they will occur at all.  (Predictions of changes to the 
installed base of widely-adopted services are almost always wrong.)

The danger of critical dependencies like these is that the current work cannot 
become widely useful unless and until those dependencies are satisfied.

Hence, the current charter guarantees that the shim6 work will never be widely 
useful, if IPv6 does not gain wide adoption OR if it must operate through 
NATs.

And please note that I said "or" and not "and".  Hence, the probabilities of 
adoption barriers are multiplicative, ie, essentially exponentially worse.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Sun, 27 Mar 2005 16:57:13 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Sun, 27 Mar 2005 11:56:24 -0500
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6" <[email-masked]>

Your completely missing the point of 3493 and some of the most brilliant
and serious network programmers in the IETF worked on this API for
years.  Your statements or assumptions are invalid completely.  3493 is
an update to BSD style sockets API with the enhancements of a more
friendly API interface getaddrinfo and getnameinfo.  In fact extensions
for those APIs for multihoming are very possible and there is no need to
invent another API but just extensions.  In addition 3493 permits a
means to program with IPv4 and IPv6 in address family indepdent manner.

> or so we'll find ourselves in the same situation. (And I'm 
> not a career 
> programmer, so maybe this isn't so much an issue for those 
> who are, but 
> I find the current API almost unusably complex and arcane.)

By your own admission above your statemeents on this topic, state your
not qualified to make a Subject Matter Expert (SME) opinion, so I
suggest you do not.  All of us that worked extensively on 3493 and those
acknowledged and from the IPv6 were SMEs on this topic.  

/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Sunday, March 27, 2005 7:55 AM
> To: Bound, Jim
> Cc: shim6
> Subject: Re: shim - transport/app communication
> 
> On 26-mrt-05, at 16:50, Bound, Jim wrote:
> 
> > Your chances of another API other than 3493 and getting multihomed
> > solution deployed in the real world of implementors and products is 
> > very
> > slim.  I also do not believe this is necessary.  The ULID concept
> > requires much more details and grilling technically.
> 
> I agree. If we had a clean API, the multihoming issue would have been 
> much easier to solve. But we don't, so we have to do it the hard way. 
> We still need to work on an architecturally clean API at some point, 
> both because it's the right thing to do and because 20 years from now 
> or so we'll find ourselves in the same situation. (And I'm 
> not a career 
> programmer, so maybe this isn't so much an issue for those 
> who are, but 
> I find the current API almost unusably complex and arcane.)
> 
> 

Delivery-date: Sun, 27 Mar 2005 13:22:33 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proposed text for charter
Date: Sun, 27 Mar 2005 15:22:09 +0200
To: Geoff Huston <[email-masked]>

On 24-mrt-05, at 21:26, Geoff Huston wrote:

> o  Changes in the addresses that are used below the shim will be 
> invisible
>    to the upper layers, which will see a fixed address (called Upper 
> Layer
>    Identifier or ULID).

> o  ULIDs will be actual IP addresses, permitting existing applications 
> to
>    continue to work unchanged, and permitting application referrals to
>    work, as long as the IP Addresses are available.

Should we mention that the ULID is one of the locators explicitly?

> o  Compatibility will remain for existing mobility mechanisms. It will 
> be
>    possible to continue using Mobile IPv6 when using Shim6 
> simultaneously.
>    However, any optimizations or advanced configurations are out of 
> scope
>    for shim6.

I believe someone else already mentioned that possibly having both 
MIPv6 and SHIM6 engaged at the same time may be problematic. It would 
be good enough (not optimal of course) if the shim would take measures 
to avoid getting in the way of MIP, even if this means mobility and 
multihoming can't happen simultaneously.

> o  The approach is to provide an optimized way to handle a static set 
> of
>    addresses, while also providing a way to securely handle dynamic
>    changes in the set of addresses. The dynamic changes might be useful
>    for future combinations of multihoming and IP mobility, but the 
> working
>    group will not take on such mobility capabilities directly.

"Dynamic changes" is too ambiguous. Obviously any solution will have to 
be able to dynamically drop addresses. However, I don't think we should 
mandate the capability of dynamically add previously unknown addresses 
to existing sessions or associations. We know that this is hard and the 
usefulness of this feature almost entirely lies outside pure 
multihoming. So way should probably keep the option of _not_ doing this 
open.

> MAY 05    First draft on cryptographic locators, if required

Does this include HBA?

Delivery-date: Sun, 27 Mar 2005 12:55:51 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Sun, 27 Mar 2005 14:55:05 +0200
To: "Bound, Jim" <[email-masked]>

On 26-mrt-05, at 16:50, Bound, Jim wrote:

> Your chances of another API other than 3493 and getting multihomed
> solution deployed in the real world of implementors and products is 
> very
> slim.  I also do not believe this is necessary.  The ULID concept
> requires much more details and grilling technically.

I agree. If we had a clean API, the multihoming issue would have been 
much easier to solve. But we don't, so we have to do it the hard way. 
We still need to work on an architecturally clean API at some point, 
both because it's the right thing to do and because 20 years from now 
or so we'll find ourselves in the same situation. (And I'm not a career 
programmer, so maybe this isn't so much an issue for those who are, but 
I find the current API almost unusably complex and arcane.)

Delivery-date: Sat, 26 Mar 2005 16:16:31 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Sat, 26 Mar 2005 11:16:16 -0500
From: "Bound, Jim" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "shim6" <[email-masked]>

Question:

Given we solve the rehoming in some manner.

App switches to new address on same interface to new ISP.  

Does this mean the transport layer state is maintained?  I assume not
but want to be sure we are all on the same page.

What does this mean to the user?  

Answer the application must restart.....

I believe the answer applies if new interface is used too ergo going
from 802.11 to GPRS on handheld?

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Geoff Huston
> Sent: Thursday, March 24, 2005 3:26 PM
> To: shim6
> Subject: Re: proposed text for charter
> 
> At 06:39 AM 25/03/2005, [email-masked] wrote:
> >Hi,
> >
> >While it does not offer everything I would want, I am fairly 
> comfortable with the charter as currently proposed.
> 
> I've added in milestones, background documents, and chartered 
> work items to this proposed text, and the text then looks as follows:
> 
> 
> For the purposes of redundancy, load sharing, operational 
> policy or cost, a
> site may be multihomed, with the site's network having connections to
> multiple IP service providers. The current Internet routing 
> infrastructure
> permits multihoming using provider-in dependant addressing, 
> and adapts to
> changes in the availability of these connections. However if 
> the site uses
> multiple provider-assigned address prefixes for every host 
> within the site,
> host application associations cannot use alternate paths, such as for
> surviving the changes or for creating new associations, when 
> one or more of
> the site's address prefixes becomes unreachable. This working 
> group will
> produce specifications for an IPv6-based site multihoming 
> solution that
> inserts a new sub-layer (shim) into the IP stack of 
> end-system hosts. It
> will enable hosts on multihomed sites to use a set of 
> provider-assigned IP
> address prefixes and switch between them without upsetting transport
> protocols or applications.
> 
> The work will be based on the architecture developed by the 
> IETF multi6
> working group. The shim6 working group is to complete the 
> required protocol
> developments and the architecture and security analysis of 
> the required
> protocols.
> 
> Requirements for the solution are:
> 
> o  The approach must handle rehoming both existing communication and
>    being able to establish new communication when one or more of the
>    addresses is unreachable.
> 
> o  IPv6 NAT devices are assumed not to exist, or not to present an
>    obstacle about which the shim6 solution needs to be concerned.
> 
> o  Only IPv6 is considered.
> 
> o  Changes in the addresses that are used below the shim will 
> be invisible
>    to the upper layers, which will see a fixed address 
> (called Upper Layer
>    Identifier or ULID).
> 
> o  ULIDs will be actual IP addresses, permitting existing 
> applications to
>    continue to work unchanged, and permitting application referrals to
>    work, as long as the IP Addresses are available.
> 
> o  The solution should assume ingress filtering may be 
> applied at network
>    boundaries.
> 
> o  The solution must allow the global routing system to scale 
> even if there
>    is a very large number of multihomed sites. This implies 
> that re-homing
>    not be visible to the routing system.
> 
> o  Compatibility will remain for existing mobility 
> mechanisms. It will be
>    possible to continue using Mobile IPv6 when using Shim6 
> simultaneously.
>    However, any optimizations or advanced configurations are 
> out of scope
>    for shim6.
> 
> o  The approach is to provide an optimized way to handle a 
> static set of
>    addresses, while also providing a way to securely handle dynamic
>    changes in the set of addresses. The dynamic changes might 
> be useful
>    for future combinations of multihoming and IP mobility, 
> but the working
>    group will not take on such mobility capabilities directly.
> 
> The background documents to be considered by the WG include:
> 
>  RFC 3582
>  draft-ietf-multi6-architecture-04.txt
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
> 
> The input documents that the WG will use as the basis for its 
> design are:
> 
>  draft-huston-l3shim-arch-00.txt
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt 
>  draft-ietf-multi6-failure-detection-00.txt
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>  
> In addition to the network layer shim solution, the shim6 WG is
> specifically chartered to work on:
> 
>      o Solutions for site exit router selection that works 
> when each ISP 
>        uses ingress filtering, i.e. when the chosen site exit 
> needs to be
>        related to the source address chosen by the host. This solution
>        should work whether or not the peer site supports the shim6
>        protocol.
> 
>      o Solutions to establish new communications after an outage has
>        occurred that does not requires shim support from the 
> non-multihomed
>        end of the communication. The wg will explore if such 
> solutions are
>        also useful when both ends support the shim.
> 
>      o Congestion control and explore how this and other QoS and
>        traffic engineering issues may interact with the use 
> of multiple
>        locators at both ends.
> 
>      o The relationships between Upper Layer Identifiers (ULIDs)
>        and Unique Local Addresses.
> 
>      o ICMP error demuxing for locator failure discovery.
> 
>      o If necessary, develop and specify formats and structure for:
> 
>        - Cryptographically protected locators
> 
>        - Carrying the flow label across the shim layer 
>          defined in the multi6 architecture. 
> 
> The shim6 WG is to publish, as standards track RFCs, 
> specifications with
> enough details to allow fully interoperable implementations.
> 
> The specifications must specifically refer to all applicable 
> threats and
> describe how they are handled,  with the requirement being that the
> resulting solution not introduce any threats that make the 
> security any
> less than in today's Internet.
> 
> Milestones
> 
> MAY 05    First draft of architectural document
> MAY 05    First draft of protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on multihoming triggers description
> MAY 05    First draft on applicability statement document
> 
> SEP 05    WG last-call on architectural document
> SEP 05    WG last-call on applicability statement document
> 
> NOV 05    WG last-call on protocol document
> NOV 05    WG last-call on cryptographic locators, if required
> NOV 05    Submit completed architectural document to IESG
> NOV 05    Submit applicability statement document to IESG
> 
> JAN 06    WG last-call on multihoming triggers description
> JAN 06    Submit document on cryptographic locators to the IESG, if
>           required
> JAN 06    Submit protocol document to the IESG
> 
> MAR 06    Submit draft on multihoming triggers description to the IESG
> 
>  
>   
> 
> 
> 

Delivery-date: Sat, 26 Mar 2005 16:06:51 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Sat, 26 Mar 2005 11:06:40 -0500
From: "Bound, Jim" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: "shim6" <[email-masked]>

> Actually, it isn't even clear to me that the solutions for hand-off 
> from 3GPP to 802.11 would involve L3 mobility.  The hand-off could 
> occur between the lower layers of 3GPP and the lower layers of 
> 802.11, requiring no IP address changes at L3.
> 

This is true and how those of us deploying IPv6 on handhelds will
deliver for a few years and then some.  But please folks lets not go
here I am on all the mobility lists in the IETF and lets not do this
here we are to work on multihoming and that is very important to
handheld devices right now today for IPv6.

/jim

Delivery-date: Sat, 26 Mar 2005 16:04:15 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/network communication
Date: Sat, 26 Mar 2005 11:04:01 -0500
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

John, is correct in my view.  I think we make sure we do not break
mobility per charter statements Jaro sent out and when we are done we
can see if there is benefit to mobility.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, March 22, 2005 7:56 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: shim - transport/network communication
> 
> Brian and Joe,
> 
> > > In that case we are saying the same thing -- dictating 
> what "best" means 
> > > (or, from another point of view, considering that there 
> is only one 
> > > "best" way) is a Bad Idea.
> > > 
> > 
> > That's why, in the architecture of shim6, IMHO we should clearly
> > separate the process of choosing the next address pair to use
> > from the process of actually starting to use those addresses. The
> > first part (choosing) I would regard as a pluggable component where
> > implementers will no doubt learn with experience, and probably need
> > not even be standardized.
> 
> I definately agree that this is orthogonal to the shim6 work. 
> You could
> imagine "best" being the most stable or reliable; highest 
> capacity; lowest
> cost; lowest latency, etc.  I think Thierry brought up the 
> issue of letting
> the user choose this, and in a wireless case (WLAN vs GPRS) 
> this makes sense.
> 
> NSIS is building upon RSVP for path-related information; PCE 
> & IPFix are working
> on somewhat related issues with regards to finding out path 
> information.  Some
> smart folks might want to pair shim6 with some of the above 
> for getting information
> about the possible network paths that the address pair 
> combinations traverse.
> Coupling that with a policy, then, for selecting the 
> addresses, probably would
> give Fred what he wants.  
> 
> Building this into the protocol is not a good idea, in my 
> opinion, but leaving
> it for implementors / future work sounds good.  This topic 
> also revolves
> around failure detection - how do we detect when there has been a path
> failure and what constitutes a path failure is open for some 
> interpretation.
> 
> I think the address-pair (or path) selection policy will be 
> very different in many 
> deployment scenarios, so again I think that this shouldn't be 
> part of what shim6 
> solves, but allowing shim6 to be one piece of the solution is 
> a good idea.
> Now we just have to progress on shim6.
> 
> John
> 
> 

Delivery-date: Sat, 26 Mar 2005 16:02:33 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Sat, 26 Mar 2005 11:02:15 -0500
From: "Bound, Jim" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "shim6" <[email-masked]>

I think the below is excellent charter statement but I would add we are
still investigating the shim and further technical discussion is
warranted.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Tuesday, March 22, 2005 10:22 AM
> To: shim6
> Subject: proposed text for charter
> 
> 
> Here's some suggested text for the shim6 charter that attempts
> to make it clearer what problem the group solves and what
> constraints are placed on the solution:
> 
> OLD:
> 
> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. The multi6 WG was tasked with investigating solutions to the site
> multihoming problem that will allow the global routing system to
> scale. The outcome of the multi6 WG is a specific network-layer shim
> architecture for addressing and address handling of sites and
> nodes. This includes switching to different locator addresses when
> connectivity changes, but without the changes of address being visible
> to upper layers, which see a fixed Upper Layer Identifier address
> (ULID).
> 
> The shim6 WG is to complete this work with the required protocol
> developments
> and complete the architecture and security analysis of the required
> protocols.
> 
> NEW:
> 
> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. An earlier multi6 WG was tasked with investigating 
> solutions to the site
> multihoming problem. The outcome of the multi6 WG was a specific
> network-layer shim architecture for addressing and address handling of
> sites and nodes.
> 
> The multihoming problem consists of the ability of sites or nodes to
> be connected to multiple IP service providers for the purposes of
> redundancy, load sharing, policy or cost reasons. The scope of the
> shim6 WG is to develop a solution which is characterized by the
> following constraints:
> 
> o  The solution will allow the global routing system to 
> scale. That is,
>    re-homing events and the structure of the multihomed connectivity
>    should not be visible to the routing system. As a result, 
> the solution
>    consists of the ability to switch to different locator 
> addresses when
>    connectivity changes.
> 
> o  Provider-assigned addresses are expected to be necessary, rather
>    than on relying solely on provider-independent addresses.  
> 
> o  Changes in the locator addresses will be invisible to upper layers,
>    which see a fixed Upper Layer Identifier address (ULID).
> 
> o  ULIDs are actual IP addresses such that existing applications can
>    continue to work unchanged, and that application referrals work.
> 
> o  The solution does not cause problems for mobility. That is, it
>    should be possible to continue using Mobile IPv6 even when using
>    shim6 simultaneously. However, any optimizations or advanced
>    configurations are out of scope for shim6.
> 
>     Similarly, while it is desirable that the basic building blocks of
>     shim6 be able to handle dynamic changes in the addresses,
>     the focus of the group is not in the development of a new
>     mobility solution.
> 
> o  The solution should assume ingress filtering may be applied.
> 
> o  Only IPv6 is considered.
> 
> o  No address translation is considered.
> 
> The shim6 WG is to complete the required protocol developments and the
> architecture and security analysis of the required protocols.
> 
> 
> 

Delivery-date: Sat, 26 Mar 2005 15:58:41 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/network communication
Date: Sat, 26 Mar 2005 10:58:31 -0500
From: "Bound, Jim" <[email-masked]>
To: "Baker Fred" <[email-masked]>, "Joe Abley" <[email-masked]>
Cc: <[email-masked]>, "Jeroen Massar" <[email-masked]>, "Miika Komu" <[email-masked]>

> And I worry much about a solution which, for lack of thinking about 
> such things, picks the worst path simply because it has less 
> AS's in it 
> or some such thing. We do far too much of that in the Internet.

I second this worry and I hsve it big time on this work.  The good news
is the vendors and customers have been burned now by the Internet and if
it is half baked it will simply not be implemented and all the work and
time will be done for nothing other than mental masturbation of
abstractions for multihoming.

/jim

Delivery-date: Sat, 26 Mar 2005 15:54:42 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/network communication
Date: Sat, 26 Mar 2005 10:54:33 -0500
From: "Bound, Jim" <[email-masked]>
To: "Baker Fred" <[email-masked]>, "Miika Komu" <[email-masked]>
Cc: <[email-masked]>, "Jeroen Massar" <[email-masked]>

> I find myself wondering whether we could use something akin to an 
> ICMPv6 Route Redirect to ask the network to cache such 
> disparities and 
> advise a host of a superior next hop and address pair to use at the 
> network layer when instantiating a host-host exchange...

I believe in thought this is the right architecture discussion and
approach and should be on the table.  This would inform the app of new
interface (or same) and requires to use new address or if we define them
and they don't break the APIs apart, to use the new address to the ISP.
This could be done with asynchronous signal to the current APIs used.
The abstraction presents using network information to help solve the
problem and I agree.

With SCTP this would also work very well and sorry about that :--)

/jim

Delivery-date: Sat, 26 Mar 2005 15:50:17 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Sat, 26 Mar 2005 10:50:06 -0500
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Baker Fred" <[email-masked]>
Cc: "shim6" <[email-masked]>

Your chances of another API other than 3493 and getting multihomed
solution deployed in the real world of implementors and products is very
slim.  I also do not believe this is necessary.  The ULID concept
requires much more details and grilling technically. 
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Sunday, March 20, 2005 4:00 AM
> To: Baker Fred
> Cc: shim6
> Subject: Re: shim - transport/app communication
> 
> On 19-mrt-05, at 22:32, Baker Fred wrote:
> 
> >> the only thing an application should depend on here is that it 
> >> supports IPv6 addresses
> 
> > If I could make a humble request here...
> 
> > Could we please manage to avoid the worst of the layering faults we 
> > committed in the IPv4 Internet? The thing that has made NAT 
> hard and 
> > made applications break crossing a NAT was that the 
> applications know 
> > something about addresses. Let's not do that with IPv6 applications.
> 
> It's already done. The RFC 3493 API extensions require an application 
> to know about IPv6, if only because they have to specify AF_INET6. In 
> theory, that's it, but in practice it's much worse because an IPv6 
> application really needs to cycle through all available addresses, 
> which IPv4 applications rarely do. Then there is the whole 
> IPv4-mapped 
> implementation debacle that makes writing (portable) 
> applications that 
> support both IPv4 and IPv6 rather tricky.
> 
> The only real solution that I can see here is yet another API that 
> moves address resolution out of the application, and completely hides 
> the IP version from the application.
> 
> The good news is that there should be some time to get it 
> right before 
> we need to move to whatever comes after IPv6.  :-)
> 
> 
> 

Delivery-date: Sat, 26 Mar 2005 15:48:33 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Sat, 26 Mar 2005 10:48:24 -0500
From: "Bound, Jim" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>

> >  The general issues of mobility are currently arousing some
> >  interest in the IAB, which seems the right place.
> 
> i can't imagine how or why.  the iab does not produce 
> engineering solutions. 

Emphatically and strongly agree.

/jim

Delivery-date: Sat, 26 Mar 2005 15:47:37 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Sat, 26 Mar 2005 10:46:52 -0500
From: "Bound, Jim" <[email-masked]>
To: "Baker Fred" <[email-masked]>, "Jeroen Massar" <[email-masked]>
Cc: <[email-masked]>

> Could we please manage to avoid the worst of the layering faults we 
> committed in the IPv4 Internet? The thing that has made NAT hard and 
> made applications break crossing a NAT was that the applications know 
> something about addresses. Let's not do that with IPv6 applications.

Generally I agree but as NGNs move to network virtualization Hosts (or
not routers) will perform network functions thus this cannot be the case
for all Hosts.  The key is to define what Fred means by application
above.  For example Network Management applications or Home Agents for
MIPv6 will need to know about IPv6 addresses.  Where as should an SQL
query know about IPv6 addresses and I would suggest probably not.  

So a general swoop of applications don't need to know about IPv6
addresses is not helpful without clarification.

/jim

Delivery-date: Fri, 25 Mar 2005 05:42:35 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we need to be (was Re: how mobile do we want to be)
Date: Fri, 25 Mar 2005 07:38:40 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Marcelo,

> I guess that this could be possible, but, i guess that the point is 
> that those different problems don't have the priority for the people 
> that have been working on multi6. I mean we have been working for a 
> long time to provide a site multihoming solution, imho this should be 
> top priority in this wg. Of course it would be nice that we could also 
> provide node multihoming support and mobile multihomed node support, 
> but these imho are not the priority here.
> 
> Besides, remember that we already have a mobility solution working but 
> there is no site multihoming solution out there, and people are really 
> waiting for this.

For what its worth, I agree with you.

John

Delivery-date: Thu, 24 Mar 2005 22:59:09 +0000
Date: Thu, 24 Mar 2005 17:58:37 -0500
To: Geoff Huston <[email-masked]>, shim6 <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: proposed text for charter

This is coming together quite nicely.  Thanks, Jari, Erik, Dave, 
Geoff and others!

Margaret

At 7:26 AM +1100 3/25/05, Geoff Huston wrote:
>At 06:39 AM 25/03/2005, [email-masked] wrote:
>>Hi,
>>
>>While it does not offer everything I would want, I am fairly 
>>comfortable with the charter as currently proposed.
>
>I've added in milestones, background documents, and chartered work 
>items to this proposed text, and the text then looks as follows:
>
>
>For the purposes of redundancy, load sharing, operational policy or cost, a
>site may be multihomed, with the site's network having connections to
>multiple IP service providers. The current Internet routing infrastructure
>permits multihoming using provider-in dependant addressing, and adapts to
>changes in the availability of these connections. However if the site uses
>multiple provider-assigned address prefixes for every host within the site,
>host application associations cannot use alternate paths, such as for
>surviving the changes or for creating new associations, when one or more of
>the site's address prefixes becomes unreachable. This working group will
>produce specifications for an IPv6-based site multihoming solution that
>inserts a new sub-layer (shim) into the IP stack of end-system hosts. It
>will enable hosts on multihomed sites to use a set of provider-assigned IP
>address prefixes and switch between them without upsetting transport
>protocols or applications.
>
>The work will be based on the architecture developed by the IETF multi6
>working group. The shim6 working group is to complete the required protocol
>developments and the architecture and security analysis of the required
>protocols.
>
>Requirements for the solution are:
>
>o  The approach must handle rehoming both existing communication and
>    being able to establish new communication when one or more of the
>    addresses is unreachable.
>
>o  IPv6 NAT devices are assumed not to exist, or not to present an
>    obstacle about which the shim6 solution needs to be concerned.
>
>o  Only IPv6 is considered.
>
>o  Changes in the addresses that are used below the shim will be invisible
>    to the upper layers, which will see a fixed address (called Upper Layer
>    Identifier or ULID).
>
>o  ULIDs will be actual IP addresses, permitting existing applications to
>    continue to work unchanged, and permitting application referrals to
>    work, as long as the IP Addresses are available.
>
>o  The solution should assume ingress filtering may be applied at network
>    boundaries.
>
>o  The solution must allow the global routing system to scale even if there
>    is a very large number of multihomed sites. This implies that re-homing
>    not be visible to the routing system.
>
>o  Compatibility will remain for existing mobility mechanisms. It will be
>    possible to continue using Mobile IPv6 when using Shim6 simultaneously.
>    However, any optimizations or advanced configurations are out of scope
>    for shim6.
>
>o  The approach is to provide an optimized way to handle a static set of
>    addresses, while also providing a way to securely handle dynamic
>    changes in the set of addresses. The dynamic changes might be useful
>    for future combinations of multihoming and IP mobility, but the working
>    group will not take on such mobility capabilities directly.
>
>The background documents to be considered by the WG include:
>
>  RFC 3582
>  draft-ietf-multi6-architecture-04.txt
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
>
>The input documents that the WG will use as the basis for its design are:
>
>  draft-huston-l3shim-arch-00.txt
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt
>  draft-ietf-multi6-failure-detection-00.txt
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>
>In addition to the network layer shim solution, the shim6 WG is
>specifically chartered to work on:
>
>      o Solutions for site exit router selection that works when each ISP
>        uses ingress filtering, i.e. when the chosen site exit needs to be
>        related to the source address chosen by the host. This solution
>        should work whether or not the peer site supports the shim6
>        protocol.
>
>      o Solutions to establish new communications after an outage has
>        occurred that does not requires shim support from the non-multihomed
>        end of the communication. The wg will explore if such solutions are
>        also useful when both ends support the shim.
>
>      o Congestion control and explore how this and other QoS and
>        traffic engineering issues may interact with the use of multiple
>        locators at both ends.
>
>      o The relationships between Upper Layer Identifiers (ULIDs)
>        and Unique Local Addresses.
>
>      o ICMP error demuxing for locator failure discovery.
>
>      o If necessary, develop and specify formats and structure for:
>
>        - Cryptographically protected locators
>
>        - Carrying the flow label across the shim layer
>          defined in the multi6 architecture.
>
>The shim6 WG is to publish, as standards track RFCs, specifications with
>enough details to allow fully interoperable implementations.
>
>The specifications must specifically refer to all applicable threats and
>describe how they are handled,  with the requirement being that the
>resulting solution not introduce any threats that make the security any
>less than in today's Internet.
>
>Milestones
>
>MAY 05    First draft of architectural document
>MAY 05    First draft of protocol document
>MAY 05    First draft on cryptographic locators, if required
>MAY 05    First draft on multihoming triggers description
>MAY 05    First draft on applicability statement document
>
>SEP 05    WG last-call on architectural document
>SEP 05    WG last-call on applicability statement document
>
>NOV 05    WG last-call on protocol document
>NOV 05    WG last-call on cryptographic locators, if required
>NOV 05    Submit completed architectural document to IESG
>NOV 05    Submit applicability statement document to IESG
>
>JAN 06    WG last-call on multihoming triggers description
>JAN 06    Submit document on cryptographic locators to the IESG, if
>           required
>JAN 06    Submit protocol document to the IESG
>
>MAR 06    Submit draft on multihoming triggers description to the IESG
>
>
>

Delivery-date: Thu, 24 Mar 2005 21:23:23 +0000
From: Dave Crocker <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 24 Mar 2005 13:22:44 -0800
Subject: Re: proposed text for charter

Tidbits...

On Fri, 25 Mar 2005 07:26:14 +1100, Geoff Huston wrote:
>  For the purposes of redundancy, load sharing, operational policy or cost, a
>  site may be multihomed, with the site's network having connections to
>  multiple IP service providers. The current Internet routing infrastructure
>  permits multihoming using provider-in dependant addressing, and adapts to
                                      ------------
                                      independant

>  changes in the availability of these connections. However if the site uses
>  multiple provider-assigned address prefixes for every host within the site,
>  host application associations cannot use alternate paths, such as for
>  surviving the changes or for creating new associations, when one or more of

[[ yes.  nice clarification. ]]

>  the site's address prefixes becomes unreachable. This working group will
>  produce specifications for an IPv6-based site multihoming solution that
>  inserts a new sub-layer (shim) into the IP stack of end-system hosts. It
>  will enable hosts on multihomed sites to use a set of provider-assigned IP
>  address prefixes and switch between them without upsetting transport
>  protocols or applications.
>
>  The work will be based on the architecture developed by the IETF multi6
>  working group. The shim6 working group is to complete the required protocol
>  developments and the architecture and security analysis of the required
>  protocols.
>
>  Requirements for the solution are:
>
>  o  The approach must handle rehoming both existing communication and
>  being able to establish new communication when one or more of the
>  addresses is unreachable.
>
>  o  IPv6 NAT devices are assumed not to exist, or not to present an
>  obstacle about which the shim6 solution needs to be concerned.
>
>  o  Only IPv6 is considered.
>
>  o  Changes in the addresses that are used below the shim will be invisible
>  to the upper layers, which will see a fixed address (called Upper Layer
>  Identifier or ULID).
>
>  o  ULIDs will be actual IP addresses, permitting existing applications to
>  continue to work unchanged, and permitting application referrals to
>  work, as long as the IP Addresses are available.
>
>  o  The solution should assume ingress filtering may be applied at network
>  boundaries.
>
>  o  The solution must allow the global routing system to scale even if there
>  is a very large number of multihomed sites. This implies that re-homing
>  not be visible to the routing system.
>
>  o  Compatibility will remain for existing mobility mechanisms. It will be
>  possible to continue using Mobile IPv6 when using Shim6 simultaneously.
>  However, any optimizations or advanced configurations are out of scope
>  for shim6.
>
>  o  The approach is to provide an optimized way to handle a static set of
>  addresses, while also providing a way to securely handle dynamic
>  changes in the set of addresses. The dynamic changes might be useful
>  for future combinations of multihoming and IP mobility, but the working
>  group will not take on such mobility capabilities directly.
>
>  The background documents to be considered by the WG include:
>
>  RFC 3582
>  draft-ietf-multi6-architecture-04.txt
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
>
>  The input documents that the WG will use as the basis for its design are:
>
>  draft-huston-l3shim-arch-00.txt
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt
>  draft-ietf-multi6-failure-detection-00.txt
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>
>  In addition to the network layer shim solution, the shim6 WG is
>  specifically chartered to work on:
>
>  o Solutions for site exit router selection that works when each ISP
                                                   -----
                                                   work

>  uses ingress filtering, i.e. when the chosen site exit needs to be
>  related to the source address chosen by the host. This solution
>  should work whether or not the peer site supports the shim6
>  protocol.

[[ is the last sentence really a separate bullet?  if not, i don't understand 
how only the ingress issue can work without the other side supporting shim6.  
if yes, i STILL don't understand how it can work. offhand, it seems 
impossible. ]]

>  o Solutions to establish new communications after an outage has
>  occurred that does not requires shim support from the non-multihomed
                 ----
                 do

>  end of the communication. The wg will explore if such solutions are
                                 --              --
                                 working group   whether

>  also useful when both ends support the shim.
>
>  o Congestion control and explore how this and other QoS and
                           ^to

>  traffic engineering issues may interact with the use of multiple
>  locators at both ends.
           ^(topology-specific addresses)

>  o The relationships between Upper Layer Identifiers (ULIDs)
>  and Unique Local Addresses.

[[ "Unique Local Addresses" is in caps, so presumably it is a term of art, but 
it is not defined here.  It should be.  However I'm not 100% certain I know 
what it means. ]]

>  o ICMP error demuxing for locator failure discovery.

[[ sounds interesting.  what is it? ]]

>  o If necessary, develop and specify formats and structure for:
>
>  - Cryptographically protected locators
>
>  - Carrying the flow label across the shim layer
>  defined in the multi6 architecture.
>
>  The shim6 WG is to publish, as standards track RFCs, specifications with
                                                  xxxxx

>  enough details to allow fully interoperable implementations.
>
>  The specifications must specifically refer to all applicable threats and
>  describe how they are handled,  with the requirement being that the
>  resulting solution not introduce any threats that make the security any
>  less than in today's Internet.
>
>  Milestones
>
>  MAY 05    First draft of architectural document
>  MAY 05    First draft of protocol document
>  MAY 05    First draft on cryptographic locators, if required
>  MAY 05    First draft on multihoming triggers description
>  MAY 05    First draft on applicability statement document
>
>  SEP 05    WG last-call on architectural document
>  SEP 05    WG last-call on applicability statement document
>
>  NOV 05    WG last-call on protocol document
>  NOV 05    WG last-call on cryptographic locators, if required
>  NOV 05    Submit completed architectural document to IESG
>  NOV 05    Submit applicability statement document to IESG
>
>  JAN 06    WG last-call on multihoming triggers description
>  JAN 06    Submit document on cryptographic locators to the IESG, if
>  required
>  JAN 06    Submit protocol document to the IESG
>
>  MAR 06    Submit draft on multihoming triggers description to the IESG

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Thu, 24 Mar 2005 20:26:40 +0000
Date: Fri, 25 Mar 2005 07:26:14 +1100
To: shim6 <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: proposed text for charter

At 06:39 AM 25/03/2005, [email-masked] wrote:
>Hi,
>
>While it does not offer everything I would want, I am fairly comfortable with the charter as currently proposed.

I've added in milestones, background documents, and chartered work items to this proposed text, and the text then looks as follows:

For the purposes of redundancy, load sharing, operational policy or cost, a
site may be multihomed, with the site's network having connections to
multiple IP service providers. The current Internet routing infrastructure
permits multihoming using provider-in dependant addressing, and adapts to
changes in the availability of these connections. However if the site uses
multiple provider-assigned address prefixes for every host within the site,
host application associations cannot use alternate paths, such as for
surviving the changes or for creating new associations, when one or more of
the site's address prefixes becomes unreachable. This working group will
produce specifications for an IPv6-based site multihoming solution that
inserts a new sub-layer (shim) into the IP stack of end-system hosts. It
will enable hosts on multihomed sites to use a set of provider-assigned IP
address prefixes and switch between them without upsetting transport
protocols or applications.

The work will be based on the architecture developed by the IETF multi6
working group. The shim6 working group is to complete the required protocol
developments and the architecture and security analysis of the required
protocols.

Requirements for the solution are:

o  The approach must handle rehoming both existing communication and
   being able to establish new communication when one or more of the
   addresses is unreachable.

o  IPv6 NAT devices are assumed not to exist, or not to present an
   obstacle about which the shim6 solution needs to be concerned.

o  Only IPv6 is considered.

o  Changes in the addresses that are used below the shim will be invisible
   to the upper layers, which will see a fixed address (called Upper Layer
   Identifier or ULID).

o  ULIDs will be actual IP addresses, permitting existing applications to
   continue to work unchanged, and permitting application referrals to
   work, as long as the IP Addresses are available.

o  The solution should assume ingress filtering may be applied at network
   boundaries.

o  The solution must allow the global routing system to scale even if there
   is a very large number of multihomed sites. This implies that re-homing
   not be visible to the routing system.

o  Compatibility will remain for existing mobility mechanisms. It will be
   possible to continue using Mobile IPv6 when using Shim6 simultaneously.
   However, any optimizations or advanced configurations are out of scope
   for shim6.

o  The approach is to provide an optimized way to handle a static set of
   addresses, while also providing a way to securely handle dynamic
   changes in the set of addresses. The dynamic changes might be useful
   for future combinations of multihoming and IP mobility, but the working
   group will not take on such mobility capabilities directly.

The background documents to be considered by the WG include:

 RFC 3582
 draft-ietf-multi6-architecture-04.txt
 draft-ietf-multi6-things-to-think-about-01.txt
 draft-ietf-multi6-multihoming-threats-03.txt

The input documents that the WG will use as the basis for its design are:

 draft-huston-l3shim-arch-00.txt
 draft-ietf-multi6-functional-dec-00.txt
 draft-ietf-multi6-l3shim-00.txt 
 draft-ietf-multi6-failure-detection-00.txt
 draft-ietf-multi6-hba-00.txt
 draft-ietf-multi6-app-refer-00.txt
 
In addition to the network layer shim solution, the shim6 WG is
specifically chartered to work on:

     o Solutions for site exit router selection that works when each ISP 
       uses ingress filtering, i.e. when the chosen site exit needs to be
       related to the source address chosen by the host. This solution
       should work whether or not the peer site supports the shim6
       protocol.

     o Solutions to establish new communications after an outage has
       occurred that does not requires shim support from the non-multihomed
       end of the communication. The wg will explore if such solutions are
       also useful when both ends support the shim.

     o Congestion control and explore how this and other QoS and
       traffic engineering issues may interact with the use of multiple
       locators at both ends.

     o The relationships between Upper Layer Identifiers (ULIDs)
       and Unique Local Addresses.

     o ICMP error demuxing for locator failure discovery.

     o If necessary, develop and specify formats and structure for:

       - Cryptographically protected locators

       - Carrying the flow label across the shim layer 
         defined in the multi6 architecture. 

The shim6 WG is to publish, as standards track RFCs, specifications with
enough details to allow fully interoperable implementations.

The specifications must specifically refer to all applicable threats and
describe how they are handled,  with the requirement being that the
resulting solution not introduce any threats that make the security any
less than in today's Internet.

Milestones

MAY 05    First draft of architectural document
MAY 05    First draft of protocol document
MAY 05    First draft on cryptographic locators, if required
MAY 05    First draft on multihoming triggers description
MAY 05    First draft on applicability statement document

SEP 05    WG last-call on architectural document
SEP 05    WG last-call on applicability statement document

NOV 05    WG last-call on protocol document
NOV 05    WG last-call on cryptographic locators, if required
NOV 05    Submit completed architectural document to IESG
NOV 05    Submit applicability statement document to IESG

JAN 06    WG last-call on multihoming triggers description
JAN 06    Submit document on cryptographic locators to the IESG, if
          required
JAN 06    Submit protocol document to the IESG

MAR 06    Submit draft on multihoming triggers description to the IESG

  

Delivery-date: Thu, 24 Mar 2005 19:39:24 +0000
From: [email-masked]
Subject: Re: proposed text for charter
Date: Thu, 24 Mar 2005 14:39:02 -0500
To: shim6 <[email-masked]>

Hi,

While it does not offer everything I would want, I am fairly 
comfortable with the charter as currently proposed.

I do wonder about the statement on NATS, i.e. whether it is a 
reasonable assumption, but won't quibble about it here and now.

a.

On 24 mar 2005, at 11.37, Dave Crocker wrote:

> Folks,
>
> Erik's draft is quite thorough.  I've done some wordsmithing, 
> especially to
> make the first paragraph fully make the case for the working group 
> effort,
> since the first paragraph is circulated independently as a summary.
>
> I've also re-ordered requirements a bit, trying to move from basics, to
> operations, to derivative issues
>
> So...
>
>
> For the purposes of redundancy, load sharing, operational policy or 
> cost, a
> site may be multihomed, with the site's network having connections to
> multiple IP service providers. Although the current Internet routing
> infrastructure permits multihoming, and adapts to changes in the 
> availability
> of these connections, host application associations cannot use these
> alternate paths, such as for surviving the changes or for creating new
> associations when one or more of the site's addresses becomes 
> unreachable.
> This working group will produce specifications for an IPv6-based site
> multihoming solution that inserts a new sub-layer (shim) into the IP 
> stack of
> end-system hosts. It will permit hosts on multihomed sites to use 
> different
> provider-assigned IP addresses and switch between them without 
> upsetting
> transport protocols or applications.
>
> The work will be based on the architecture developed by the IETF multi6
> working group. The shim6 working group is to complete the required 
> protocol
> developments and the architecture and security analysis of the required
> protocols.
>
> Requirements for the solution are:
>
> o  The approach must handle rehoming both existing communication and
>    being able to establish new communication when one or more of the
>    addresses is unreachable.
>
> o  IPv6 NAT devices are assumed not to exist, or not to present an
>    obstacle about which the shim6 solution needs to be concerned.
>
> o  Only IPv6 is considered.
>
> o  Changes in the addresses that are used below the shim will be 
> invisible to
>    the upper layers, which will see a fixed address (called Upper Layer
>    Identifier or ULID).
>
> o  ULIDs will be actual IP addresses, permitting existing applications 
> to
>    continue to work unchanged, and permitting application referrals to 
> work,
>    as long as the IP Addresses are available. Applications that do 
> referrals
>    and want to fully exploit the alternate communication paths, such 
> as for
>    handling path failures, either need to use domain names, or to pass 
> lists
>    of destination IP addresses when doing referrals.
>
> o  The solution should assume ingress filtering may be applied.
>
> o  The solution must allow the global routing system to scale even if 
> there
>    is a very large number of multihomed sites. This implies that 
> re-homing
>    not be visible to the routing system.
>
> o  Compatibility will remain for existing mobility mechanisms. It will 
> be
>    possible to continue using Mobile IPv6 even when using Shim6
>    simultaneously. However, any optimizations or advanced 
> configurations are
>    out of scope for shim6.
>
> o  The approach provides an optimized way to handle a static set of
>    addresses, while also providing a way to securely handle dynamic
>    changes in the set of addresses. The dynamic changes might be useful
>    for future combinations of multihoming and IP mobility, but the 
> working
>    group will not take on such mobility capabilities directly.
>
>
>
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
>
>
>
>

Delivery-date: Thu, 24 Mar 2005 17:04:20 +0000
Date: Thu, 24 Mar 2005 18:04:06 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: shim6 <[email-masked]>
Subject: Re: proposed text for charter

> It will be 
>    possible to continue using Mobile IPv6 even when using Shim6 
>    simultaneously.

I think that is too agressive. I would buy

   It will possible to use Mobile IPv6 on a node that also supports Shim6.

I think it is entirely possible that MIP will have to tell shim6 to
switch itself off in some circumstances.

    Brian

Delivery-date: Thu, 24 Mar 2005 16:38:36 +0000
From: Dave Crocker <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 24 Mar 2005 08:37:42 -0800
Subject: Re: proposed text for charter

Folks,

Erik's draft is quite thorough.  I've done some wordsmithing, especially to 
make the first paragraph fully make the case for the working group effort, 
since the first paragraph is circulated independently as a summary.

I've also re-ordered requirements a bit, trying to move from basics, to 
operations, to derivative issues

So...

For the purposes of redundancy, load sharing, operational policy or cost, a
site may be multihomed, with the site's network having connections to
multiple IP service providers. Although the current Internet routing
infrastructure permits multihoming, and adapts to changes in the availability
of these connections, host application associations cannot use these
alternate paths, such as for surviving the changes or for creating new
associations when one or more of the site's addresses becomes unreachable.
This working group will produce specifications for an IPv6-based site
multihoming solution that inserts a new sub-layer (shim) into the IP stack of
end-system hosts. It will permit hosts on multihomed sites to use different
provider-assigned IP addresses and switch between them without upsetting
transport protocols or applications.

The work will be based on the architecture developed by the IETF multi6
working group. The shim6 working group is to complete the required protocol
developments and the architecture and security analysis of the required
protocols.

Requirements for the solution are:

o  The approach must handle rehoming both existing communication and
   being able to establish new communication when one or more of the
   addresses is unreachable.

o  IPv6 NAT devices are assumed not to exist, or not to present an
   obstacle about which the shim6 solution needs to be concerned.

o  Only IPv6 is considered.

o  Changes in the addresses that are used below the shim will be invisible to
   the upper layers, which will see a fixed address (called Upper Layer
   Identifier or ULID).

o  ULIDs will be actual IP addresses, permitting existing applications to
   continue to work unchanged, and permitting application referrals to work, 
   as long as the IP Addresses are available. Applications that do referrals 
   and want to fully exploit the alternate communication paths, such as for 
   handling path failures, either need to use domain names, or to pass lists 
   of destination IP addresses when doing referrals.

o  The solution should assume ingress filtering may be applied.

o  The solution must allow the global routing system to scale even if there
   is a very large number of multihomed sites. This implies that re-homing
   not be visible to the routing system.

o  Compatibility will remain for existing mobility mechanisms. It will be 
   possible to continue using Mobile IPv6 even when using Shim6 
   simultaneously. However, any optimizations or advanced configurations are 
   out of scope for shim6.

o  The approach provides an optimized way to handle a static set of
   addresses, while also providing a way to securely handle dynamic
   changes in the set of addresses. The dynamic changes might be useful
   for future combinations of multihoming and IP mobility, but the working
   group will not take on such mobility capabilities directly.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Thu, 24 Mar 2005 13:13:53 +0000
Date: Thu, 24 Mar 2005 15:13:32 +0200
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: proposed text for charter

Hi Erik,

Your edits look very good, thanks! One nit below:

>
> The solution must allow the global routing system to scale even if 
> there is a very large number of multihomed sites. This implies that 
> re-homing not not be visible to the routing system. As a result, the 
> necessary approach

s/not not/not/

--Jari

Delivery-date: Thu, 24 Mar 2005 09:48:19 +0000
From: Dave Crocker <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>, <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 24 Mar 2005 01:48:09 -0800
Subject: Re: how mobile do we need to be (was Re: how mobile do we want to be)

On Wed, 23 Mar 2005 21:23:23 +0100, marcelo bagnulo braun wrote:
>  I guess that we should keep in mind that SHIM will deal with _site_
>  multihoming, and not node multihoming

Marcelo,

The differences between host and site multihoming, in terms of physical 
connectivity, are presumably obvious -- the only variable I can think of is 2 
different Internet links to the same IP router, versus different links to 
different routers.

That said, I'm not sure I understand how the difference affects the shim6 
design.  Highlighting this difference, in the charter, would be helpful.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Thu, 24 Mar 2005 09:42:11 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we need to be (was Re: how mobile do we want to be)
Date: Wed, 23 Mar 2005 21:23:23 +0100
To: [email-masked]

Hi Avri,

El 23/03/2005, a las 7:36, [email-masked] escribió:

>
> On 22 mar 2005, at 17.22, Margaret Wasserman wrote:
>
>> At 11:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
>>> That would require some serious voodoo as these are nearly always 
>>> managed by different entities. So essentially this would keep the 
>>> problem the same but require wifi base stations and gsm/umts 
>>> infrastructure to solve this and hide the complexity from the hosts. 
>>> This isn't traditionally the way the IETF does things.
>>
>> I was actually expecting that, to get this to work well, you'd need 
>> to purchase the 3GPP/802.11 roaming service from a single provider...
>
> I don't expect this to be the case in all cases.
>
> In my view of things there is definitely a case where L3 could 
> reasonably be involved.
>
> What I expect to happen is that a 3G/802 equipped device/node would 
> move into a zone where 802 was possible and  where at some point it 
> could be connected to two or more providers at the same time, sort of 
> multihomed. During this interval it could have separate addresses 
> given by different providers. And as in any multihomed node it could 
> chose which provider to use based on its own policy constraints.  As 
> it moved from one zone's prevalence to another or from one provider's 
> area to another, the balance would change and different providers, and 
> L3 addressing possibilities, could become available.
>
> And while it is true that one could use the extensive machinery of MIP 
> to make this work, it seems to me that using the multihoming shim's 
> capabilities could be a lighter weight possibility.  But while it is 
> possible that support for this sort of movement could just fall out of 
> the shims specialized for static and fixed multihoming,

I guess that we should keep in mind that SHIM will deal with _site_ 
multihoming, and not node multihoming
I guess that all this discussion is about host multihoming, which could 
benefit from mobility support

So, i am not sure how much sense it makes to demand mobility support in 
the site mutlihoming scenario, unless you are considering something 
like a NEMO, which has not been really the focus in the discussion.

I mean there is a lot of context and unstated assumptions here. I guess 
that we are here to provide a site multihoming solution. Then since the 
site mutlihoming solution recommended by the multi6 wg is based on a 
shim, now we are also considering to use it to provide host multihoming 
(which is already out of the scope of the SHIM imho) and then we want 
that the site mutlihoming solution also provides support to a mobile 
node.

I guess that this could be possible, but, i guess that the point is 
that those different problems don't have the priority for the people 
that have been working on multi6. I mean we have been working for a 
long time to provide a site multihoming solution, imho this should be 
top priority in this wg. Of course it would be nice that we could also 
provide node multihoming support and mobile multihomed node support, 
but these imho are not the priority here.

Besides, remember that we already have a mobility solution working but 
there is no site multihoming solution out there, and people are really 
waiting for this.

So, imho we should really focus in the site mutlihoming case, and of 
course we should keep a broad view in order not to do any _arbitrary_ 
choices that disable the usage of the shim for node multihoming and 
even mobility support, but this should not be the focus of our work 
now, and imho the support for mobilty should not be cosidered as 
importand the the real goal of this work, which is site mutlihoming 
support.

and just a final comment: i really don't think SHIM sill be a lighter 
weight option for mobility support, perhaps it may be attractive for 
other reasons, but not for being lighter.

rgeards, marcelo

>  I expect that support of a dynamic multihoming model, i.e. one with 
> movement, might hold some gotchas.  I would prefer to see us deal with 
> these during the architectural and protocol design stage then to have 
> to deal with them in the deployment stage when the solutions might end 
> up as afterthoughts, i.e addon hacks.
>
> One thing I am pretty sure is that if it is possible to coerce shims 
> into doing dynamic multihoming, i.e. multihoming with movement, then 
> someone will.  Given that it probably will happen, it might be better 
> to design for it.
>
> a.
>
>

Delivery-date: Thu, 24 Mar 2005 00:34:07 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Wed, 23 Mar 2005 19:33:41 -0500
From: "Bound, Jim" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Kurtis Lindqvist" <[email-masked]>, "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>, "Leif Johansson" <[email-masked]>, <[email-masked]>

Hi Eric, 

> Bound, Jim wrote:
> 
> >>Nobody has proposed changing the IP addresses that are seen 
> >>on the wire. 
> >>All we are changing is to add a dynamic mapping between what IP 
> >>addresses the transport and above sees (the ULIDs) and the IP 
> >>addresses 
> >>the routing system sees.
> > 
> > 
> > That is not crystal clear to me in the spec above at all.
> 
> OK. If you have specific things that are unclear I can make a pass at 
> clarifying those in the next rev.

OK I will as I can.  I think the key issue is to clearly state IP
addresses are on the wire not ULIDs. Then for applications what do ULID
semantically look like exactly, or to current management interfaces on a
node etc.

> 
> 
> > Something different.  Map an TCP request to an SCTP request 
> as if the
> > transport selected was SCTP.
> 
> But that has quite more limited applicability than a shim.

That is not my point but I am not sure I agree.  My point is SCTP solves
the problem of passing ULIDs with an extension, and in addition supports
inherent failover of IP addresses to a new interface within its
architecture.  If passing ULIDs is in fact a good idea.

> First of all, the peer need to do the same (which is also the 
> case for 
> the shim) thus you need a very performant approach to 
> failback to using 
> TCP when the peer doesn't support this.

Why does this matter? If only addresses are passed on the wire.  ULIDs
should only be beneficial operationally to a node local scope not
between other nodes or peers is my view, other than to find an address.

> It is hard for me to see an 
> approach using SCTP that can be as efficient as the shim, because the 
> shim defers its work thus there is no extra work (state or 
> packets) for 
> short-lived connections.

As I said most of what is needed to failover to a new interface and
address is in fact part of SCTP. Much of the shim is to operate with
locators and that I am not convinced is warranted overhead to solve the
multihoming problem at all.

> But the SCTP providing the TCP socket API also has the issue that the 
> SCTP protocol can't provide the identical service as TCP, 
> with all the 
> details of TCP urgent data being the prime example. Even if almost no 
> applications use that aspect of TCP, it means that you can't 
> claim 100% 
> compatibility for the SCTP approach, whereas the shim can 
> make such a claim.

We can get close enough until this is implemented more efficiently and
then transition to SCTP.

Also I am less concerned about locators and identification than the more
important issue of failover to new ISP and interface which I think is
the first order of business.  This will reduce sending to same address
to same ISP etc or all the issues of not having specific address and
interface for different ISP and solve the real problem which is having
ISPs have to hold all perhost routes for another ISP.

> Finally, SCTP doesn't help for UDP communication.

That is true but UDP won't work that well for failover of address and
interface either with the shim approach.  Regarding passing ULID that
can be lightweight UDP protocol we define though, if that is important.

> 
> So while SCTP has many useful features, I don't see it as the 
> ideal fit 
> for something that we want to shim in under existing applications and 
> have everything work without application changes.

I think it depends which problem is to be solved.  If just failover to
new interface and potentially new address I think SCTP solves the
reliable transport problem better.  

If it is just a matter of ULID use then maybe not.

I also fail to see at all how ULID solves the issue of failover to new
interface and adddress except as round robin essentially in the kernel
and this could be done in user space if we had a ULID format and
architecture then shim would only be optional regarding implementation
of the method.

> Thus I'm interesting in figuring out how SCTP and the shim 
> can work well 
> together for the many cases where SCTP is the right transport 
> protocol 
> to use.

Well first question is do two nodes need to pass ULIDs to each other?   

> 
> 
> >>I'd like to understand why you think a DST option in every 
> packet is 
> >>necessary. Such a thing would be complete untrusted.
> > 
> > 
> > Yes the trust would be a problem.  Could be reference to 
> look for ULID new
> > extension header then which could be encrypted with IPsec 
> then.  The reason
> > to pass the ULIDs is to save processing on each node for 
> mapping to them at
> > the transport and above.  This shim now will require a 
> search for ULID on
> > every packet. Providing the ULID in the packet avoids that 
> on every system?
> 
> If you want intermediaries (middleboxes) to use the ULID, 
> then carrying 
> it encrypted doesn't help, since they either don't have the 
> key (hence 
> can't decrypt to read the ULID), or they have the key and can 
> spoof the 
> ULID and thereby fool the next middle box.

I find such a concept of middle boxes doing this quite evil and breaks
end-to-end so I don't care about middle boxes and in industry state
strongly don't use them except as service when required to be called by
an app. So your telling this to the wrong architect/engineer :--)

> 
> For the endpoint, the processing to lookup the context state and find 
> the ULID is quite small, and in the common case of the ULID being the 
> same as the locator (which is the case before any failure has 
> happened)
> close to zero.
> For example, if the shim and no failure happens, the packets would be 
> the same as today (IPv6 followed by TCP, for instance) and the shim 
> would be close to a no-op. (I say "close to", because the shim might 
> want to count the number of packets so that it can determine whether 
> this is a long-lived communication i.e. whether it is worth-while to 
> establish multi6 state so that the communication can be 
> rehomed should a 
> failure occur).
> After a failure has occurred and the communication has been 
> rehomed to 
> use a different address pair, then the receiver needs to lookup the 
> context state and modify the packet before passing it to TCP etc.
> That does entail a lookup operation, but depending on details in the 
> protocol design it might be possible to have this be just an array 
> lookup based on an index in the packet (that's part of what 
> the receive 
> side demultiplexing issue is about in the shim draft).

The address pair reference above is what SCTP does so well and can do
better than TCP.

So what is the added value of a ULID or concept of locator?  I simply
think this is unecessary.

> 
> >>Thus it would be 
> >>better if middleboxes that want to do verification either
> >>  - get explicitly signaled from the endpoints so that they 
> >>have the list
> >>    of IP addresses
> >>  - observe the sim6 signaling protocol and do the same 
> >>verification as
> >>    the endpoints do as a way to discover the list of IP addresses
> >>Both of those can be reasonably secure.
> > 
> > 
> > Yes that is possible but was trying to avoid this and keep 
> e2e only and as
> > needed also if they change that can be accomodated too.
> 
> Agreed.
> 
> I was confused and thought you wanted the DST option for 
> middleboxes and 
> not for the endpoints

Yes for the end points.

I guess from architecture view I do not believe we need locators to
solve the multihome problem at all too..
> 
>     Erik

Thanks
/jim

Delivery-date: Thu, 24 Mar 2005 00:34:07 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Wed, 23 Mar 2005 19:33:46 -0500
From: "Bound, Jim" <[email-masked]>
To: "Dirk Henrici" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is sooooooooo true.  In 90% of the cases the way this plays out in
industry is the apps require to be ported to use the new feature.  For
access to the IP stack most new APIs today can do it in AF and Transport
friendly manner but that requires an initial port.  

/jim 

> -----Original Message-----
> From: Dirk Henrici [mailto:[email-masked]] 
> Sent: Wednesday, March 23, 2005 5:33 AM
> To: [email-masked]; [email-masked]; Bound, Jim; [email-masked]
> Subject: Re: shim - transport/app communication
> 
> It seems that the same problems are talked about in many discussions, 
> not only in this list:
> 
> Today
> - apps need to be aware of addresses
> - apps are bound to certain transport protocols at design 
> time, in fact
>    UDP and TCP
> 
> This makes introducing new protocols (e.g. IPv6, SCTP) a very 
> hard task.
> 
> 
> Baker Fred wrote:
> > On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
> >> the only thing an application should depend on here is that it 
> >> supports IPv6 addresses
> > 
> > 
> > If I could make a humble request here...
> > 
> > Could we please manage to avoid the worst of the layering faults we 
> > committed in the IPv4 Internet? The thing that has made NAT 
> hard and 
> > made applications break crossing a NAT was that the 
> applications know 
> > something about addresses. Let's not do that with IPv6 applications.
> > 
> > Applications should know about names and APIs, period. They 
> should open 
> > a socket-or-whatever to a name, and accept that the service 
> underneath 
> > gets them to an instantiation of it.
> 
> Iljitsch van Beijnum wrote:
>  > The only real solution that I can see here is yet another API that
>  > moves address resolution out of the application, and 
> completely hides 
>  > the IP version from the application.
> 
> Bound, Jim wrote:
>  > Something different.  Map an TCP request to an SCTP 
> request as if the
>  > transport selected was SCTP.
> 
> 
> I think that introducing a layer that maps TCP requests to 
> SCTP requests 
> is no more than a short term solution. It is time to solve the REAL 
> problem: that applications are aware of the network layer and the 
> transport layer.
> 
> I agree with Iljitsch and the others that another API as a long term 
> alternative to the "good old" socket API is needed.
> 
> This API should be crafted in such a way that protocols at the 
> network/transport layer can be changed transparently without 
> affecting 
> applications any more.
> To enable this, applications should specify which "services" 
> they need 
> (e.g. bidirectional reliable messages, low delay) and a new layer 
> between applications and transport layer selects and uses the most 
> appropriate protocols available with which the desired destination is 
> reachable.
> 
> Of course, this is off-topic in this working group here. But a newly 
> created working group could address the topic. What do you 
> think about that?
> A collegue of mine is doing his PhD on that topic. I'm sure he could 
> provide a lot of input...
> 
> 
>    Dirk
> 
> 

Delivery-date: Wed, 23 Mar 2005 21:48:47 +0000
Date: Wed, 23 Mar 2005 13:48:07 -0800
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: proposed text for charter

Jari Arkko wrote:

Some suggested edits on your proposed text.
First I list the suggested result, followed by the changes:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG. An earlier multi6 WG was tasked with investigating solutions to the
site multihoming problem. The outcome of the multi6 WG was a specific
network-layer shim architecture for addressing and address handling of
sites and nodes.

The multihoming problem consists of the ability of sites or nodes to
be connected to multiple IP service providers for the purposes of
redundancy, load sharing, policy or cost reasons.

The solution must allow the global routing system to scale even if there 
is a very large number of multihomed sites. This implies that re-homing 
not not be visible to the routing system. As a result, the necessary 
approach is to be able to use different provider assigned IP addresses 
and switch between them without upsetting transport protocols or 
applications.

The attributes of the approach that was developped in multi6, which map 
to requirements for the shim6 solution, are:

o  Changes in the addresses used below the shim will be invisible to
    upper layers, which see a fixed address (called Upper Layer
    Identifier or ULID).

o  ULIDs are actual IP addresses such that existing applications can
    continue to work unchanged, and that application referrals work.
	Applications that do referrels and want to fully exploit the
	communication paths e.g., to handle failures, either need to
	operate on domain names, or pass lists of IP addresses when
	doing referrals.

o  The solution must not cause problems for mobility. That is, it
    should be possible to continue using Mobile IPv6 even when using
    shim6 simultaneously. However, any optimizations or advanced
    configurations are out of scope for shim6.

o The approach provides an optimized way to handle a static set of
   addresses, while also providing a way to securely handle dynamic
   changes in the set of addresses. The dynamic changes might be useful
   for future combinations of multihoming and IP mobility, but the WG
   will not take on the full mobility problem.

o The approach must handle rehoming both existing communication and
   being able to establish new communication when one or more of the
   addresses is unreachable.

o  The solution should assume ingress filtering may be applied.

o  Only IPv6 is considered.

o  Assume that IPv6 NAT devices wither will not exist, or will not be an
    obstacle that shim6 needs to be concerned with.

The shim6 WG is to complete the required protocol developments and the
architecture and security analysis of the required protocols.

    Erik

"Diffs":

> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. An earlier multi6 WG was tasked with investigating solutions to the 
> site
> multihoming problem. The outcome of the multi6 WG was a specific
> network-layer shim architecture for addressing and address handling of
> sites and nodes.

ok

> The multihoming problem consists of the ability of sites or nodes to
> be connected to multiple IP service providers for the purposes of
> redundancy, load sharing, policy or cost reasons. 

Here I'd add the top level issue about using multiple PA addresses:
The solution must allow the global routing system to scale even if there 
is a very large number of multihome sites. This implies that re-homing 
not not be visible to the routing system. As a result, the necessary 
approach is to be able to use different provider assigned IP addresses 
and switch between them without upsetting transport protocols or 
applications.

The attributes of the approach that was developped in multi6, which map 
to requirements
for the shim6 solution, are:

> o Changes in the locator addresses will be invisible to upper layers,
>   which see a fixed Upper Layer Identifier address (ULID).

Makes sense to reword so that charter doesn't have to introduce the 
terms "locator address" and "ULID address".

> o  ULIDs are actual IP addresses such that existing applications can
>   continue to work unchanged, and that application referrals work.

Add:
	Applications that do referrels and want to fully exploit the
	communication paths e.g., to handle failures, either need to
	operate on domain names, or pass lists of IP addresses when
	doing referrals.

> o  The solution does not cause problems for mobility. That is, it
s/does not/must not/
>   should be possible to continue using Mobile IPv6 even when using
>   shim6 simultaneously. However, any optimizations or advanced
>   configurations are out of scope for shim6.

ok

>    Similarly, while it is desirable that the basic building blocks of
>    shim6 be able to handle dynamic changes in the addresses,
>    the focus of the group is not in the development of a new
>    mobility solution.

Reword as:
o The approach provides an optimized way to handle a static set of 
addresses, while also providing a way to securely handle dynamic changes 
in the set of addresses. The dynamic changes might be useful for future 
combinations of multihoming and IP mobility, but the WG will not take on 
the full mobility problem.

I think we also need a bullet about existing communication and 
establishing new communication.

> o  The solution should assume ingress filtering may be applied.
> 
> o  Only IPv6 is considered.
> 
> o  No address translation is considered.

I think this means "IPv6 NAT" (as opposed to the "translation" the shim 
does at both ends) so it makes sense to say that explicitly.

> The shim6 WG is to complete the required protocol developments and the
> architecture and security analysis of the required protocols.
> 
> 

Delivery-date: Wed, 23 Mar 2005 19:47:58 +0000
Date: Wed, 23 Mar 2005 21:47:51 +0200
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: proposed text for charter

Hi Erik,

>
> While the text is certainly more informative, I'm not sure this is
> a complete list of constraints, requirements, or goals.
> So is this a list of considerations (which isn't necessarily 
> complete), or is it a mixture of assumptions (such as multiple PA 
> addresses being used)?

Well, it was my list of most important constraints, requirements, and
goals. I acknowledge that it might not be complete. Do you have
something specific to add? Would you like to have a list of considerations,
or a full list of constraints/requirements/goals?

(Btw, I viewed PA addresses more as a constraint on the solution than an
assumption -- after all, if we could use PI addresses the solution would
be quite different. But my understanding was that this wouldn't be
possible for the type of target "market" that we are looking at.)

>> o  ULIDs are actual IP addresses such that existing applications can
>>   continue to work unchanged, and that application referrals work.
>
> The draft-ietf-multi6-app-refer is a bit more nuanced than just "work 
> unchanged". Based on what we know today, we can make unmodified 
> applications work as long as all the address pairs are working, but in 
> order for the referal-type cases to take advantage of all the address 
> pairs, the applications doing referals either need to use FQDNs, or 
> lists of addresses instead of a single address.

Yes, that's right. Do you have suggested text?

--Jari

Delivery-date: Wed, 23 Mar 2005 19:16:48 +0000
Date: Wed, 23 Mar 2005 11:16:05 -0800
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: shim6 <[email-masked]>
Subject: Re: how mobile do we need to be (was Re: how mobile do we want to be)

[email-masked] wrote:

> One thing I am pretty sure is that if it is possible to coerce shims 
> into doing dynamic multihoming, i.e. multihoming with movement, then 
> someone will.  Given that it probably will happen, it might be better to 
> design for it.

Avri,

Based on the discussions so far I haven't seen anybody being 
uncomfortable with adding wording about handling a dynamic set of 
addresses to the charter.
And I'm all for it; it matches what I see as being needed to enable 
future optimizations/combinations of multihoming and different forms of 
mobility.

But this is very different than having a charter should say that we 
solve (IP)mobility+multihoming. There are lots of questions and 
different views in the IETF how to handle the "fixpoint" aspect of 
something that moves; whether done using IP routing, DNS name, SIP 
registrations, etc, etc.
And we don't want to try to resolve such disagreements in a shim6 group.
Hence to me it makes a lot of sense to allow the "fixpoint" aspects to 
be orthogonal to the mechanisms for managing the address pairs.

Note that any dynamic multihoming would have applicability limited by 
the frequency at one can change IP addresses and notify the peer of the 
new address(es) without to much packet loss during the roundtrip time. 
Thus, there would still be a need for L2 mobility management for 
handling frequent, local movement without effecting the IP addresses.

    Erik

Delivery-date: Wed, 23 Mar 2005 19:10:47 +0000
Date: Wed, 23 Mar 2005 21:10:24 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked], Margaret Wasserman <[email-masked]>, Dave Crocker <[email-masked]>, Brian E Carpenter <[email-masked]>
Subject: Re: charter [Re: how mobile do we want to be]

On Tue, 22 Mar 2005, marcelo bagnulo braun wrote:
> So, as i see it this covers the ingress filtering problem, the establishement 
> of new communications after an outage and the preservation of new 
> communications.

Agreed.  I counted being able to deal with ingress filtering and 
(obviously) being able to establish new communications after an outage 
as implicit requirements for the work, not needing spelling out.  But 
it doesn't hurt, of course.

> Besides, some understanding of TE concerns is also within scope (ok, i agree 
> that probably we won't be able to achieve features equivalent to those 
> available in BGP v4 solution with respect to this)

Exactly.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Wed, 23 Mar 2005 19:04:46 +0000
Date: Wed, 23 Mar 2005 11:04:12 -0800
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: proposed text for charter

Jari Arkko wrote:

> The multihoming problem consists of the ability of sites or nodes to
> be connected to multiple IP service providers for the purposes of
> redundancy, load sharing, policy or cost reasons. The scope of the
> shim6 WG is to develop a solution which is characterized by the
> following constraints:

While the text is certainly more informative, I'm not sure this is
a complete list of constraints, requirements, or goals.
So is this a list of considerations (which isn't necessarily complete), 
or is it a mixture of assumptions (such as multiple PA addresses being 
used)?

> o  ULIDs are actual IP addresses such that existing applications can
>   continue to work unchanged, and that application referrals work.

The draft-ietf-multi6-app-refer is a bit more nuanced than just "work 
unchanged". Based on what we know today, we can make unmodified 
applications work as long as all the address pairs are working, but in 
order for the referal-type cases to take advantage of all the address 
pairs, the applications doing referals either need to use FQDNs, or 
lists of addresses instead of a single address.

    Erik

Delivery-date: Wed, 23 Mar 2005 19:00:03 +0000
Date: Wed, 23 Mar 2005 10:59:14 -0800
From: Vijay Devarapalli <[email-masked]>
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: how mobile do we want to be

[email-masked] wrote:
> Margaret,
> 
> 
>>I know that this isn't how we typically do things in the IETF. 
>>However, I am not sure that we are doing this in the IETF.  The only 
>>place I know that this particular problem is being considered is in 
>>the IEEE (802.21, IIRC).   It also seems likely to me that some of 
>>the cell phone standards bodies are looking at this (3GPP or 3GPP2, 
>>for instance), but I haven't heard of anything specific going on 
>>there, have you?
>>
>>I think that mobile IP could be used for something like this, but not 
>>without cooperation from the cell phone providers, right?
> 
> 
> Going further off-topic - in 3GPP, interworking is being specified.
> MIP and Mobike are being considered for solutions for session continuity;
> but then there are technologies like UMA which essentially tunnels the
> cellular protocols over WLAN.  This Iljitsch would probably consider
> serious voodoo, but that is fodder for more off-topic posts.
> 
> 3GPP2 is already using MIPv4 and has interest in MIPv6 and are studying
> how to provide session continuity for CDMA - WLAN handovers; MIP being
> a strong potential candidate. My info on this may be somewhat outdated,
> though.

the current working assumption for 3GPP2-WLAN interworking is to
use Mobile IP when handing off between WLAN and cdma2000 networks.
the specification is going on currently.

Vijay

Delivery-date: Wed, 23 Mar 2005 16:46:38 +0000
Cc: [email-masked], Margaret Wasserman <[email-masked]>, Dave Crocker <[email-masked]>, Brian E Carpenter <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: charter [Re: how mobile do we want to be]
Date: Tue, 22 Mar 2005 21:17:56 +0100
To: Pekka Savola <[email-masked]>

Hi Pekka,

> After all, we are not solving "the site multihoming problem" so we 
> don't reference an architecture document -- just one but possibly 
> important subset of it.  Namely, connection survivability across 
> failures when using multiple PA addresses... everything else is bonus.
>

Well, i am not fully agree with you here.

I mean the charter does state that

Site-multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG.

...

In addition to the basic network layer shim solution, the shim6 WG
is specifically chartered to do work on

       o Solutions for site exit router selection that works when each 
ISP
         uses ingress filtering, i.e. when the chosen site exit needs to
be
         related to the source address chosen by the host. This solution
         should work whether or not the peer site supports the shim6
protocol.

       o Solutions to establish new communications after an outage has
         occurred that does not requires shim support from the
         non-multihomed end of the communication. The wg will explore
         if such solutions are also useful when both ends support the
shim.

       o Congestion control and explore how this and other QoS and
         traffic engineering issues may interact with the use of
         multiple locators at both ends.

So, as i see it this covers the ingress filtering problem, the 
establishement of new communications after an outage and the 
preservation of new communications.
Besides, some understanding of TE concerns is also within scope (ok, i 
agree that probably we won't be able to achieve features equivalent to 
those available in BGP v4 solution with respect to this)

So, i guess the charter is wider than just preserving established 
communications.

Regards, marcelo

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

Delivery-date: Wed, 23 Mar 2005 15:07:21 +0000
Date: Wed, 23 Mar 2005 16:05:43 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: proposed text for charter

I'm supportive.

And btw, I have made a note to myself to abstain from the IESG
decision when this charter comes up for review.

    Brian

[email-masked] wrote:
> Jari,
> 
> I can live with your proposed text, I'll suggest some wordsmithing in a few
> places, if folks are roughly supportive of this text.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
>>Jari Arkko
>>Sent: 22 March, 2005 17:22
>>To: shim6
>>Subject: proposed text for charter
>>
>>
>>
>>Here's some suggested text for the shim6 charter that attempts
>>to make it clearer what problem the group solves and what
>>constraints are placed on the solution:
>>
>>OLD:
>>
>>The shim6 WG is to produce specifications for an IPv6 site-multihoming
>>solution based on the architecture developed by the IETF multi6
>>WG. The multi6 WG was tasked with investigating solutions to the site
>>multihoming problem that will allow the global routing system to
>>scale. The outcome of the multi6 WG is a specific network-layer shim
>>architecture for addressing and address handling of sites and
>>nodes. This includes switching to different locator addresses when
>>connectivity changes, but without the changes of address being visible
>>to upper layers, which see a fixed Upper Layer Identifier address
>>(ULID).
>>
>>The shim6 WG is to complete this work with the required protocol
>>developments
>>and complete the architecture and security analysis of the required
>>protocols.
>>
>>NEW:
>>
>>The shim6 WG is to produce specifications for an IPv6 site-multihoming
>>solution based on the architecture developed by the IETF multi6
>>WG. An earlier multi6 WG was tasked with investigating 
>>solutions to the site
>>multihoming problem. The outcome of the multi6 WG was a specific
>>network-layer shim architecture for addressing and address handling of
>>sites and nodes.
>>
>>The multihoming problem consists of the ability of sites or nodes to
>>be connected to multiple IP service providers for the purposes of
>>redundancy, load sharing, policy or cost reasons. The scope of the
>>shim6 WG is to develop a solution which is characterized by the
>>following constraints:
>>
>>o  The solution will allow the global routing system to 
>>scale. That is,
>>   re-homing events and the structure of the multihomed connectivity
>>   should not be visible to the routing system. As a result, 
>>the solution
>>   consists of the ability to switch to different locator 
>>addresses when
>>   connectivity changes.
>>
>>o  Provider-assigned addresses are expected to be necessary, rather
>>   than on relying solely on provider-independent addresses.  
>>
>>o  Changes in the locator addresses will be invisible to upper layers,
>>   which see a fixed Upper Layer Identifier address (ULID).
>>
>>o  ULIDs are actual IP addresses such that existing applications can
>>   continue to work unchanged, and that application referrals work.
>>
>>o  The solution does not cause problems for mobility. That is, it
>>   should be possible to continue using Mobile IPv6 even when using
>>   shim6 simultaneously. However, any optimizations or advanced
>>   configurations are out of scope for shim6.
>>
>>    Similarly, while it is desirable that the basic building blocks of
>>    shim6 be able to handle dynamic changes in the addresses,
>>    the focus of the group is not in the development of a new
>>    mobility solution.
>>
>>o  The solution should assume ingress filtering may be applied.
>>
>>o  Only IPv6 is considered.
>>
>>o  No address translation is considered.
>>
>>The shim6 WG is to complete the required protocol developments and the
>>architecture and security analysis of the required protocols.
>>
>>
>>
> 
> 
> 

Delivery-date: Wed, 23 Mar 2005 10:25:18 +0000
Date: Wed, 23 Mar 2005 11:25:09 +0100
From: Julien Laganier <[email-masked]>
Subject: Re: how mobile do we want to be
To: Jari Arkko <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]

Hi Jari,

Jari Arkko wrote:
> Iljitsch,
> 
> 
>>Please don't forget: adding a new address in the middle of a session 
>>is a security nightmare. The only way this can be done reasonably is 
>>with the help of strong crypto (magic PKI dust) or a home agent that 
>>is impervious to
>>
> 
> I'm getting a bit frustrated on this thread. I sympathize on the need
> to have a constrained problem to work on. But obviously we are in any
> case using strong crypto, or would you not call HBAs strong crypto? And as
> I have explained in a previous e-mail, PKI means infrastructure
> and we have a number of known techniques (some even implemented
> by several teams) that can do mobility with public keys, but without
> any need for infrastructure.

FWIW, I agree with this, and I also support the charter proposal you
posted earlier.

Furthermore, I think that, because a negotiation would be needed anyway
to detect if the remote end is shim-enabled, this negotiation is an
opportunity to negotiate between CGA/public key crypto/"mobile
multihoming" and HBA/hash functions/"static multihoming".

Hence, all shim-enabled nodes would be required to implement the later
(which is suitable to constrained devices) without preventing stronger
nodes to implement the former if they benefits from it. In case a
constrained device communicates with an unconstrained one, both would
only benefit from the HBA-based readressing, which is still better than
nothing.

Thanks,

--julien

Delivery-date: Wed, 23 Mar 2005 10:21:42 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Wed, 23 Mar 2005 11:21:19 +0100
To: Thierry Ernst <[email-masked]>

On 23-mrt-05, at 3:07, Thierry Ernst wrote:

>> You have to drill a bit deeper as mobile phones aren't an application
>> so it's impossible to determine whether they need layer 4 stability on
>>  top of layer 3 mobility.

> I'm afraid I don't understand the comment, but if it's what I think, I
> would answer that to me it's pretty clear they need layer 4 stability.

No it's not. The only application I would really want this for is 
remote login, but with the right tools reestablishing such a session is 
trivial.

It would be nice to keep a/v streams running when switching 
infrastructures, but congestion issues make this very problematic.

I think someone else mentioned one other application that could use 
layer 4 stability on top of layer 3 changes, but I can't find this. 
Stuff like web and file transfer don't need this capability, and in 
mail only downloading large attachments would be helped by it, but 
changing the pop/imap protocols can address this just as easily.

I suspect that the "need" for mobility is 99% driven by bell-heads who 
still think in terms of services that must provide a seamless 
experience to the user. Guess what: the "user" is a big company 
building complex software, and if they can handle stuff like this 
themselves (for instance, by restarting file transfers after an 
interruption) they'll be happy to do so.

> I think that the discussion is about putting the right thing in the
> charter, so I don't think it's coming at the wrong moment - rather at
> the right time, before the WG is approved.

My answer remains the same: "not now". What could go into the charter 
about mobility that would be helpful at this point in time? (And "we 
need mobility, you guys figure it out!" doesn't qualify as "helpful".) 
The wg can always recharter after finishing some specified amount of 
work.

Delivery-date: Wed, 23 Mar 2005 10:08:26 +0000
Content-class: urn:content-classes:message
Subject: RE: proposed text for charter
Date: Wed, 23 Mar 2005 12:03:41 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jari,

I can live with your proposed text, I'll suggest some wordsmithing in a few
places, if folks are roughly supportive of this text.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Jari Arkko
> Sent: 22 March, 2005 17:22
> To: shim6
> Subject: proposed text for charter
> 
> 
> 
> Here's some suggested text for the shim6 charter that attempts
> to make it clearer what problem the group solves and what
> constraints are placed on the solution:
> 
> OLD:
> 
> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. The multi6 WG was tasked with investigating solutions to the site
> multihoming problem that will allow the global routing system to
> scale. The outcome of the multi6 WG is a specific network-layer shim
> architecture for addressing and address handling of sites and
> nodes. This includes switching to different locator addresses when
> connectivity changes, but without the changes of address being visible
> to upper layers, which see a fixed Upper Layer Identifier address
> (ULID).
> 
> The shim6 WG is to complete this work with the required protocol
> developments
> and complete the architecture and security analysis of the required
> protocols.
> 
> NEW:
> 
> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. An earlier multi6 WG was tasked with investigating 
> solutions to the site
> multihoming problem. The outcome of the multi6 WG was a specific
> network-layer shim architecture for addressing and address handling of
> sites and nodes.
> 
> The multihoming problem consists of the ability of sites or nodes to
> be connected to multiple IP service providers for the purposes of
> redundancy, load sharing, policy or cost reasons. The scope of the
> shim6 WG is to develop a solution which is characterized by the
> following constraints:
> 
> o  The solution will allow the global routing system to 
> scale. That is,
>    re-homing events and the structure of the multihomed connectivity
>    should not be visible to the routing system. As a result, 
> the solution
>    consists of the ability to switch to different locator 
> addresses when
>    connectivity changes.
> 
> o  Provider-assigned addresses are expected to be necessary, rather
>    than on relying solely on provider-independent addresses.  
> 
> o  Changes in the locator addresses will be invisible to upper layers,
>    which see a fixed Upper Layer Identifier address (ULID).
> 
> o  ULIDs are actual IP addresses such that existing applications can
>    continue to work unchanged, and that application referrals work.
> 
> o  The solution does not cause problems for mobility. That is, it
>    should be possible to continue using Mobile IPv6 even when using
>    shim6 simultaneously. However, any optimizations or advanced
>    configurations are out of scope for shim6.
> 
>     Similarly, while it is desirable that the basic building blocks of
>     shim6 be able to handle dynamic changes in the addresses,
>     the focus of the group is not in the development of a new
>     mobility solution.
> 
> o  The solution should assume ingress filtering may be applied.
> 
> o  Only IPv6 is considered.
> 
> o  No address translation is considered.
> 
> The shim6 WG is to complete the required protocol developments and the
> architecture and security analysis of the required protocols.
> 
> 
> 

Delivery-date: Wed, 23 Mar 2005 06:36:35 +0000
From: [email-masked]
Subject: how mobile do we need to be (was Re: how mobile do we want to be)
Date: Wed, 23 Mar 2005 01:36:21 -0500
To: shim6 <[email-masked]>

On 22 mar 2005, at 17.22, Margaret Wasserman wrote:

> At 11:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
>> That would require some serious voodoo as these are nearly always 
>> managed by different entities. So essentially this would keep the 
>> problem the same but require wifi base stations and gsm/umts 
>> infrastructure to solve this and hide the complexity from the hosts. 
>> This isn't traditionally the way the IETF does things.
>
> I was actually expecting that, to get this to work well, you'd need to 
> purchase the 3GPP/802.11 roaming service from a single provider...

I don't expect this to be the case in all cases.

In my view of things there is definitely a case where L3 could 
reasonably be involved.

What I expect to happen is that a 3G/802 equipped device/node would 
move into a zone where 802 was possible and  where at some point it 
could be connected to two or more providers at the same time, sort of 
multihomed. During this interval it could have separate addresses given 
by different providers. And as in any multihomed node it could chose 
which provider to use based on its own policy constraints.  As it moved 
from one zone's prevalence to another or from one provider's area to 
another, the balance would change and different providers, and L3 
addressing possibilities, could become available.

And while it is true that one could use the extensive machinery of MIP 
to make this work, it seems to me that using the multihoming shim's 
capabilities could be a lighter weight possibility.  But while it is 
possible that support for this sort of movement could just fall out of 
the shims specialized for static and fixed multihoming, I expect that 
support of a dynamic multihoming model, i.e. one with movement, might 
hold some gotchas.  I would prefer to see us deal with these during the 
architectural and protocol design stage then to have to deal with them 
in the deployment stage when the solutions might end up as 
afterthoughts, i.e addon hacks.

One thing I am pretty sure is that if it is possible to coerce shims 
into doing dynamic multihoming, i.e. multihoming with movement, then 
someone will.  Given that it probably will happen, it might be better 
to design for it.

a.

Delivery-date: Wed, 23 Mar 2005 05:24:47 +0000
Date: Wed, 23 Mar 2005 07:24:20 +0200
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: how mobile do we want to be

Iljitsch,

> Please don't forget: adding a new address in the middle of a session 
> is a security nightmare. The only way this can be done reasonably is 
> with the help of strong crypto (magic PKI dust) or a home agent that 
> is impervious to
>
I'm getting a bit frustrated on this thread. I sympathize on the need
to have a constrained problem to work on. But obviously we are in any
case using strong crypto, or would you not call HBAs strong crypto? And as
I have explained in a previous e-mail, PKI means infrastructure
and we have a number of known techniques (some even implemented
by several teams) that can do mobility with public keys, but without
any need for infrastructure.

Note: I'm not suggesting that we widen the group's focus --
there seems to be a set of people who want to work on a constrained
problem -- but lets be clear about the reasons.

--Jari

Delivery-date: Wed, 23 Mar 2005 03:28:17 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Wed, 23 Mar 2005 05:26:14 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Margaret,

> I know that this isn't how we typically do things in the IETF. 
> However, I am not sure that we are doing this in the IETF.  The only 
> place I know that this particular problem is being considered is in 
> the IEEE (802.21, IIRC).   It also seems likely to me that some of 
> the cell phone standards bodies are looking at this (3GPP or 3GPP2, 
> for instance), but I haven't heard of anything specific going on 
> there, have you?
> 
> I think that mobile IP could be used for something like this, but not 
> without cooperation from the cell phone providers, right?

Going further off-topic - in 3GPP, interworking is being specified.
MIP and Mobike are being considered for solutions for session continuity;
but then there are technologies like UMA which essentially tunnels the
cellular protocols over WLAN.  This Iljitsch would probably consider
serious voodoo, but that is fodder for more off-topic posts.

3GPP2 is already using MIPv4 and has interest in MIPv6 and are studying
how to provide session continuity for CDMA - WLAN handovers; MIP being
a strong potential candidate. My info on this may be somewhat outdated,
though.

John

Delivery-date: Wed, 23 Mar 2005 02:38:53 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Tue, 22 Mar 2005 21:38:40 -0500
From: "Bound, Jim" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Kurtis Lindqvist" <[email-masked]>, "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>, "Leif Johansson" <[email-masked]>, <[email-masked]>

Erik, down at my end will respond when I can thanks for this thread.
/jim 

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Monday, March 21, 2005 4:29 PM
> To: Bound, Jim
> Cc: Kurtis Lindqvist; Pasi Sarolahti; ext Iljitsch van 
> Beijnum; Leif Johansson; [email-masked]
> Subject: Re: shim - transport/app communication
> 
> Bound, Jim wrote:
> 
> >>Nobody has proposed changing the IP addresses that are seen 
> >>on the wire. 
> >>All we are changing is to add a dynamic mapping between what IP 
> >>addresses the transport and above sees (the ULIDs) and the IP 
> >>addresses 
> >>the routing system sees.
> > 
> > 
> > That is not crystal clear to me in the spec above at all.
> 
> OK. If you have specific things that are unclear I can make a pass at 
> clarifying those in the next rev.
> 
> 
> > Something different.  Map an TCP request to an SCTP request 
> as if the
> > transport selected was SCTP.
> 
> But that has quite more limited applicability than a shim.
> First of all, the peer need to do the same (which is also the 
> case for 
> the shim) thus you need a very performant approach to 
> failback to using 
> TCP when the peer doesn't support this. It is hard for me to see an 
> approach using SCTP that can be as efficient as the shim, because the 
> shim defers its work thus there is no extra work (state or 
> packets) for 
> short-lived connections.
> But the SCTP providing the TCP socket API also has the issue that the 
> SCTP protocol can't provide the identical service as TCP, 
> with all the 
> details of TCP urgent data being the prime example. Even if almost no 
> applications use that aspect of TCP, it means that you can't 
> claim 100% 
> compatibility for the SCTP approach, whereas the shim can 
> make such a claim.
> Finally, SCTP doesn't help for UDP communication.
> 
> So while SCTP has many useful features, I don't see it as the 
> ideal fit 
> for something that we want to shim in under existing applications and 
> have everything work without application changes.
> Thus I'm interesting in figuring out how SCTP and the shim 
> can work well 
> together for the many cases where SCTP is the right transport 
> protocol 
> to use.
> 
> 
> >>I'd like to understand why you think a DST option in every 
> packet is 
> >>necessary. Such a thing would be complete untrusted.
> > 
> > 
> > Yes the trust would be a problem.  Could be reference to 
> look for ULID new
> > extension header then which could be encrypted with IPsec 
> then.  The reason
> > to pass the ULIDs is to save processing on each node for 
> mapping to them at
> > the transport and above.  This shim now will require a 
> search for ULID on
> > every packet. Providing the ULID in the packet avoids that 
> on every system?
> 
> If you want intermediaries (middleboxes) to use the ULID, 
> then carrying 
> it encrypted doesn't help, since they either don't have the 
> key (hence 
> can't decrypt to read the ULID), or they have the key and can 
> spoof the 
> ULID and thereby fool the next middle box.
> 
> For the endpoint, the processing to lookup the context state and find 
> the ULID is quite small, and in the common case of the ULID being the 
> same as the locator (which is the case before any failure has 
> happened)
> close to zero.
> For example, if the shim and no failure happens, the packets would be 
> the same as today (IPv6 followed by TCP, for instance) and the shim 
> would be close to a no-op. (I say "close to", because the shim might 
> want to count the number of packets so that it can determine whether 
> this is a long-lived communication i.e. whether it is worth-while to 
> establish multi6 state so that the communication can be 
> rehomed should a 
> failure occur).
> After a failure has occurred and the communication has been 
> rehomed to 
> use a different address pair, then the receiver needs to lookup the 
> context state and modify the packet before passing it to TCP etc.
> That does entail a lookup operation, but depending on details in the 
> protocol design it might be possible to have this be just an array 
> lookup based on an index in the packet (that's part of what 
> the receive 
> side demultiplexing issue is about in the shim draft).
> 
> >>Thus it would be 
> >>better if middleboxes that want to do verification either
> >>  - get explicitly signaled from the endpoints so that they 
> >>have the list
> >>    of IP addresses
> >>  - observe the sim6 signaling protocol and do the same 
> >>verification as
> >>    the endpoints do as a way to discover the list of IP addresses
> >>Both of those can be reasonably secure.
> > 
> > 
> > Yes that is possible but was trying to avoid this and keep 
> e2e only and as
> > needed also if they change that can be accomodated too.
> 
> Agreed.
> 
> I was confused and thought you wanted the DST option for 
> middleboxes and 
> not for the endpoints.
> 
>     Erik
> 

Delivery-date: Wed, 23 Mar 2005 02:06:20 +0000
Date: Wed, 23 Mar 2005 11:10:48 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

On Tue, 22 Mar 2005 16:52:34 -0500
Margaret Wasserman <[email-masked]> wrote:

> At 9:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
> >>  and the original discussions, a year or so
> >>  ago, had clear examples of interest, with mobile phones switcing
> >between >  cell phone linkage and 802.11 linkage being one of the
> >more interesting.
> >
> >You have to drill a bit deeper as mobile phones aren't an 
> >application so it's impossible to determine whether they need layer 
> >4 stability on top of layer 3 mobility.
> 
> Actually, it isn't even clear to me that the solutions for hand-off 
> from 3GPP to 802.11 would involve L3 mobility.  The hand-off could 
> occur between the lower layers of 3GPP and the lower layers of 
> 802.11, requiring no IP address changes at L3.

If we want to provide the user with ubiquity and the ability to switch
from one interface to another (possibly from one provider to another) in
the course of an open session, L3 is probably the best place to do it.
At least, this is the solution on which car manufacturers and other
businesses are working, based on MIP6 or NEMO BS.

Thierry

Delivery-date: Wed, 23 Mar 2005 02:03:52 +0000
Date: Wed, 23 Mar 2005 11:07:53 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

Hi,

On Tue, 22 Mar 2005 21:05:07 +0100
Iljitsch van Beijnum <[email-masked]> wrote:

> > and the original discussions, a year or so
> > ago, had clear examples of interest, with mobile phones switcing 
> > between
> > cell phone linkage and 802.11 linkage being one of the more 
> > interesting.
> 
> You have to drill a bit deeper as mobile phones aren't an application 
> so it's impossible to determine whether they need layer 4 stability on
>  top of layer 3 mobility.

I'm afraid I don't understand the comment, but if it's what I think, I
would answer that to me it's pretty clear they need layer 4 stability.

> Let's for a moment assume that all we need for mobility is a mechanism
>  to add new addresses to existing sessions. Can you tell me what kind
>  of 
> architecture would allow this to happen in a way that is secure enough
>  that it isn't the weakest link in a mobile session over IPsec, but
>  also 
> allows for autoconfiguration and doesn't increase computational 
> requirements significantly over the current situation?
> 
> >>  We now have the situation that a group of people wants to do X. 
> >> Another
> >>  group of people wants to do X+Y. Does this mean the first group is
> > > now
> >>  obiligated to do (X+Y), even though (X+Y) is much harder to solve 
> >> than
> >>  (X)+(Y)?
> 
> > given the trauma caused by a shim-like change to the architecture
> > and  given
> > the very poor history of getting these sorts of changes adopted by
> > the Internet user community, the answer ought to be yes.
> 
> I can go along with that for a bit, because I wish I could have been 
> there when MIPv6 started and have told them that they were going down 
> the wrong path and should have included multihoming support.

This is what we want to do know, and there are have been quite a lot of
efforts in this direction overt the past 3 years (MCOA, MMI, etc ...).
Chairs and other people didn't want to add such a WG item but a large
number of people has constantly continued work on this and have actually
implemented (some of the) necessary mechanisms.

> The trouble is that the type of input you're providing right now comes
>  at the wrong time. Despite the fact that it's a BOF the shim effort
>  is 
> well underway, and starting from scratch would be a HUGE waste of
> time,  without any reason to believe that a new effort would result in
>  anything better, whatever "better" happens to be. The shim approach
>  has 
> enormous potential for synergy with lots of other stuff, so I'm sure 
> that we're going to revist lots of issues somewhere down the line. 
> There is also a lot of good oldfashioned engineering to do (protocol 
> messages, failure detection, path selection, ingress filtering, the 
> list goes on). Experience so far has shown that these areas can impose
>  unforseen restrictions, so it's very important to get them out of the
>  
> way before widening the scope.

I think that the discussion is about putting the right thing in the
charter, so I don't think it's coming at the wrong moment - rather at
the right time, before the WG is approved.

I very much agree with the last post from Jar Arkko.

Thierry

Delivery-date: Tue, 22 Mar 2005 22:53:23 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Tue, 22 Mar 2005 23:53:11 +0100
To: Margaret Wasserman <[email-masked]>

On 22-mrt-05, at 23:22, Margaret Wasserman wrote:

>> That would require some serious voodoo as these are nearly always 
>> managed by different entities. So essentially this would keep the 
>> problem the same but require wifi base stations and gsm/umts 
>> infrastructure to solve this and hide the complexity from the hosts. 
>> This isn't traditionally the way the IETF does things.

> I was actually expecting that, to get this to work well, you'd need to 
> purchase the 3GPP/802.11 roaming service from a single provider...

I'm sure the telcos would love to take over 802.11, but I don't see how 
that could happen, as most 802.11 installations are in private homes 
and businesses. The best they can do is go after road warriors and 
conferences. Maybe that's enough...

> It also seems likely to me that some of the cell phone standards 
> bodies are looking at this (3GPP or 3GPP2, for instance), but I 
> haven't heard of anything specific going on there, have you?

No, but I'm not privvy to what happens there.

> I think that mobile IP could be used for something like this, but not 
> without cooperation from the cell phone providers, right?

I guess it would be possible to do some magic between the base station 
and the handset without involvement from the telco, but I'm not sure 
it's possible to make this completely transparent to the host.

Delivery-date: Tue, 22 Mar 2005 22:26:15 +0000
Date: Tue, 22 Mar 2005 17:22:15 -0500
To: Iljitsch van Beijnum <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: shim6 <[email-masked]>

At 11:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
>That would require some serious voodoo as these are nearly always 
>managed by different entities. So essentially this would keep the 
>problem the same but require wifi base stations and gsm/umts 
>infrastructure to solve this and hide the complexity from the hosts. 
>This isn't traditionally the way the IETF does things.

I was actually expecting that, to get this to work well, you'd need 
to purchase the 3GPP/802.11 roaming service from a single provider...

I know that this isn't how we typically do things in the IETF. 
However, I am not sure that we are doing this in the IETF.  The only 
place I know that this particular problem is being considered is in 
the IEEE (802.21, IIRC).   It also seems likely to me that some of 
the cell phone standards bodies are looking at this (3GPP or 3GPP2, 
for instance), but I haven't heard of anything specific going on 
there, have you?

I think that mobile IP could be used for something like this, but not 
without cooperation from the cell phone providers, right?

Margaret

Delivery-date: Tue, 22 Mar 2005 22:05:26 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Tue, 22 Mar 2005 23:05:16 +0100
To: Margaret Wasserman <[email-masked]>

On 22-mrt-05, at 22:52, Margaret Wasserman wrote:

>> You have to drill a bit deeper as mobile phones aren't an application 
>> so it's impossible to determine whether they need layer 4 stability 
>> on top of layer 3 mobility.

> Actually, it isn't even clear to me that the solutions for hand-off 
> from 3GPP to 802.11 would involve L3 mobility.  The hand-off could 
> occur between the lower layers of 3GPP and the lower layers of 802.11, 
> requiring no IP address changes at L3.

That would require some serious voodoo as these are nearly always 
managed by different entities. So essentially this would keep the 
problem the same but require wifi base stations and gsm/umts 
infrastructure to solve this and hide the complexity from the hosts. 
This isn't traditionally the way the IETF does things.

Iljitsch

Delivery-date: Tue, 22 Mar 2005 21:55:26 +0000
Date: Tue, 22 Mar 2005 16:52:34 -0500
To: Iljitsch van Beijnum <[email-masked]>, Dave Crocker <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: shim6 <[email-masked]>

At 9:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
>>  and the original discussions, a year or so
>>  ago, had clear examples of interest, with mobile phones switcing between
>>  cell phone linkage and 802.11 linkage being one of the more interesting.
>
>You have to drill a bit deeper as mobile phones aren't an 
>application so it's impossible to determine whether they need layer 
>4 stability on top of layer 3 mobility.

Actually, it isn't even clear to me that the solutions for hand-off 
from 3GPP to 802.11 would involve L3 mobility.  The hand-off could 
occur between the lower layers of 3GPP and the lower layers of 
802.11, requiring no IP address changes at L3.

Margaret

Delivery-date: Tue, 22 Mar 2005 20:05:45 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Tue, 22 Mar 2005 21:05:07 +0100
To: Dave Crocker <[email-masked]>

On 22-mrt-05, at 14:05, Dave Crocker wrote:

>>  It's you and Avri who keep harping about mobility without addressing
>>  the technical issues that I or others bring up in response.

>>  There is no evidence that layer 3 mobility
>>  is even useful or necessary,

> that's not a technical claim.

I never claimed that all my claims are technical.

> and the original discussions, a year or so
> ago, had clear examples of interest, with mobile phones switcing 
> between
> cell phone linkage and 802.11 linkage being one of the more 
> interesting.

You have to drill a bit deeper as mobile phones aren't an application 
so it's impossible to determine whether they need layer 4 stability on 
top of layer 3 mobility.

>>  No, but it does need a home address, so you don't get multihoming 
>> with
>>  existing mobility. If you want multihoming AND mobility you need 
>> strong
>>  crypto to authenticate adding addresses to existing sessions.

> 1. the 'home address' model is needed in some mobility cases, but not
> others. To assert that one is always needed is to presume details 
> about the
> problem and solution space that haven't been stated.

Let me repeat some text from my first message to this list:

Please don't forget: adding a new address in the middle of a session is 
a security nightmare. The only way this can be done reasonably is with 
the help of strong crypto (magic PKI dust) or a home agent that is 
impervious to on-path nastiness such as sniffing and MitM. Obviously, 
for a good number of applications strong crypto isn't a problem as they 
already use it today. But mandating strong crypto for *everything* is 
very problematic for reasons of performance, configuration and 
robustness. (Let the person who never clicked "accept" on an SSL 
warning cast the first stone here.)

> 2. strong crypto is the typical choice for any mechanism that changes
> addresses within a transport association.

Not sure I understand what you're talking about.

Are you saying that we need strong crypto and I should get over it?

>>  Multihomed, mobile, simple: pick any two.

> clever, but without foundation and certainly not a 'technical issue'.

Let's for a moment assume that all we need for mobility is a mechanism 
to add new addresses to existing sessions. Can you tell me what kind of 
architecture would allow this to happen in a way that is secure enough 
that it isn't the weakest link in a mobile session over IPsec, but also 
allows for autoconfiguration and doesn't increase computational 
requirements significantly over the current situation?

>>  We now have the situation that a group of people wants to do X. 
>> Another
>>  group of people wants to do X+Y. Does this mean the first group is 
>> now
>>  obiligated to do (X+Y), even though (X+Y) is much harder to solve 
>> than
>>  (X)+(Y)?

> given the trauma caused by a shim-like change to the architecture and 
> given
> the very poor history of getting these sorts of changes adopted by the
> Internet user community, the answer ought to be yes.

I can go along with that for a bit, because I wish I could have been 
there when MIPv6 started and have told them that they were going down 
the wrong path and should have included multihoming support.

The trouble is that the type of input you're providing right now comes 
at the wrong time. Despite the fact that it's a BOF the shim effort is 
well underway, and starting from scratch would be a HUGE waste of time, 
without any reason to believe that a new effort would result in 
anything better, whatever "better" happens to be. The shim approach has 
enormous potential for synergy with lots of other stuff, so I'm sure 
that we're going to revist lots of issues somewhere down the line. 
There is also a lot of good oldfashioned engineering to do (protocol 
messages, failure detection, path selection, ingress filtering, the 
list goes on). Experience so far has shown that these areas can impose 
unforseen restrictions, so it's very important to get them out of the 
way before widening the scope.

Delivery-date: Tue, 22 Mar 2005 18:32:15 +0000
Date: Tue, 22 Mar 2005 19:31:29 +0100
From: Xiaoming Fu <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: fragmenting the solution space

Iljitsch van Beijnum wrote:
> On 14-mrt-05, at 21:02, Dave Crocker wrote:
> 
>> 2. IPv6 mobile
> 
> Ok, I'll buy this one but it would be nice if someone bothered to 
> implement it first.

Something may be of interest:
http://www.phonecontent.com/bm/news/nokia/578.shtml

Cheers,
Xiaoming

Delivery-date: Tue, 22 Mar 2005 16:04:40 +0000
Date: Tue, 22 Mar 2005 18:04:30 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: Re: how mobile do we want to be

Hello folks,

We are spending a lot of energy on this discussion. I don't
sense the two sides of the debate moving much closer to
each other. However,while the gap seems large in the discussion
and theory, I'm actually not convinced that its that large
in practise.

First of all, I think most people in this thread agreed that
shim6 should not break existing mobility mechanisms, i.e.,
Mobile IPv6. So far so good, though this may mean some
work in shim6 to ensure that its really the case.

Secondly, most people would probably find it desirable to
work (in some other bof) on more advanced combinations
of what you can achieve with shim6 and mipv6.

Thirdly, I sensed that some of you wanted to ensure
that shim6 is designed both as a multihoming solution
and as a next-generation mobility solution. This raised
a lot of technical and administrative discussion. But putting
the discussion aside for the moment, I would
like to note that there are actually some components
of a such as solution already in the current working
assumptions of our group. Namely, the possibility of
"dynamic multihoming", at least as an option, and the
use of SEND address format which might be used to
build a mobility solution, even if originally intended just
for SEND and shim6 compatibility. These building blocks are close to
what I'd choose if I had to design a zero-config ipv6-only
multihoming and mobility solution from scratch.

In conclusion, while people are saying "we are not
going to do it", there are some underlying technical
choices that have not closed the door, IF we decide
to that. This is good.

I tried to incorporate these aspects also to the charter
text proposal that I sent to the list some time ago.

--Jari

P.S. I can't resist saying that people who think its impossible
to build a solution that does both mobility and multihoming
should visit a couple of other IETF WGs and prototype labs
that appear to be doing just that, as well as handling IPv4-IPv6
and NAT traversal too :-)

Delivery-date: Tue, 22 Mar 2005 15:22:31 +0000
Date: Tue, 22 Mar 2005 17:21:48 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: proposed text for charter

Here's some suggested text for the shim6 charter that attempts
to make it clearer what problem the group solves and what
constraints are placed on the solution:

OLD:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG. The multi6 WG was tasked with investigating solutions to the site
multihoming problem that will allow the global routing system to
scale. The outcome of the multi6 WG is a specific network-layer shim
architecture for addressing and address handling of sites and
nodes. This includes switching to different locator addresses when
connectivity changes, but without the changes of address being visible
to upper layers, which see a fixed Upper Layer Identifier address
(ULID).

The shim6 WG is to complete this work with the required protocol
developments
and complete the architecture and security analysis of the required
protocols.

NEW:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG. An earlier multi6 WG was tasked with investigating solutions to the site
multihoming problem. The outcome of the multi6 WG was a specific
network-layer shim architecture for addressing and address handling of
sites and nodes.

The multihoming problem consists of the ability of sites or nodes to
be connected to multiple IP service providers for the purposes of
redundancy, load sharing, policy or cost reasons. The scope of the
shim6 WG is to develop a solution which is characterized by the
following constraints:

o  The solution will allow the global routing system to scale. That is,
   re-homing events and the structure of the multihomed connectivity
   should not be visible to the routing system. As a result, the solution
   consists of the ability to switch to different locator addresses when
   connectivity changes.

o  Provider-assigned addresses are expected to be necessary, rather
   than on relying solely on provider-independent addresses.  

o  Changes in the locator addresses will be invisible to upper layers,
   which see a fixed Upper Layer Identifier address (ULID).

o  ULIDs are actual IP addresses such that existing applications can
   continue to work unchanged, and that application referrals work.

o  The solution does not cause problems for mobility. That is, it
   should be possible to continue using Mobile IPv6 even when using
   shim6 simultaneously. However, any optimizations or advanced
   configurations are out of scope for shim6.

    Similarly, while it is desirable that the basic building blocks of
    shim6 be able to handle dynamic changes in the addresses,
    the focus of the group is not in the development of a new
    mobility solution.

o  The solution should assume ingress filtering may be applied.

o  Only IPv6 is considered.

o  No address translation is considered.

The shim6 WG is to complete the required protocol developments and the
architecture and security analysis of the required protocols.

Delivery-date: Tue, 22 Mar 2005 15:22:24 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/network communication
Date: Tue, 22 Mar 2005 14:55:34 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Brian and Joe,

> > In that case we are saying the same thing -- dictating what "best" means 
> > (or, from another point of view, considering that there is only one 
> > "best" way) is a Bad Idea.
> > 
> 
> That's why, in the architecture of shim6, IMHO we should clearly
> separate the process of choosing the next address pair to use
> from the process of actually starting to use those addresses. The
> first part (choosing) I would regard as a pluggable component where
> implementers will no doubt learn with experience, and probably need
> not even be standardized.

I definately agree that this is orthogonal to the shim6 work. You could
imagine "best" being the most stable or reliable; highest capacity; lowest
cost; lowest latency, etc.  I think Thierry brought up the issue of letting
the user choose this, and in a wireless case (WLAN vs GPRS) this makes sense.

NSIS is building upon RSVP for path-related information; PCE & IPFix are working
on somewhat related issues with regards to finding out path information.  Some
smart folks might want to pair shim6 with some of the above for getting information
about the possible network paths that the address pair combinations traverse.
Coupling that with a policy, then, for selecting the addresses, probably would
give Fred what he wants.  

Building this into the protocol is not a good idea, in my opinion, but leaving
it for implementors / future work sounds good.  This topic also revolves
around failure detection - how do we detect when there has been a path
failure and what constitutes a path failure is open for some interpretation.

I think the address-pair (or path) selection policy will be very different in many 
deployment scenarios, so again I think that this shouldn't be part of what shim6 
solves, but allowing shim6 to be one piece of the solution is a good idea.
Now we just have to progress on shim6.

John

Delivery-date: Tue, 22 Mar 2005 13:06:13 +0000
From: Dave Crocker <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 22 Mar 2005 05:05:57 -0800
Subject: Re: how mobile do we want to be

 On Tue, 22 Mar 2005 11:08:46 +0100, Iljitsch van Beijnum wrote:
>  It's you and Avri who keep harping about mobility without addressing
>  the technical issues that I or others bring up in response.

Oh?:

>  There is no evidence that layer 3 mobility
>  is even useful or necessary,

that's not a technical claim.  and the original discussions, a year or so 
ago, had clear examples of interest, with mobile phones switcing between 
cell phone linkage and 802.11 linkage being one of the more interesting.

and:

>  No, but it does need a home address, so you don't get multihoming with
>  existing mobility. If you want multihoming AND mobility you need strong
>  crypto to authenticate adding addresses to existing sessions.

1. the 'home address' model is needed in some mobility cases, but not 
others. To assert that one is always needed is to presume details about the 
problem and solution space that haven't been stated.

2. strong crypto is the typical choice for any mechanism that changes 
addresses within a transport association.

and:

>  Multihomed, mobile, simple: pick any two.

clever, but without foundation and certainly not a 'technical issue'.

>  We now have the situation that a group of people wants to do X. Another
>  group of people wants to do X+Y. Does this mean the first group is now
>  obiligated to do (X+Y), even though (X+Y) is much harder to solve than
>  (X)+(Y)?

given the trauma caused by a shim-like change to the architecture and given 
the very poor history of getting these sorts of changes adopted by the 
Internet user community, the answer ought to be yes.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Tue, 22 Mar 2005 12:54:24 +0000
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 22 Mar 2005 04:53:59 -0800
Subject: Re: charter?

 On Tue, 22 Mar 2005 13:26:13 +0100, Brian E Carpenter wrote:
>  my point, which
>  Dave chose to ignore, is that I don't know how to boil down all that
>  work into a paragraph.

ignore?  

not quite.  you and margaret both took the position that summarizing was 
difficult, apparently in the view that that made it ok for the charter to not 
do what is required of a charter:

>  So, I guess that it is difficult to summarize what problem the thing solves
>  and how it will be helpful, without requiring the evaluator to first read
>  about the physics of internal combustion engines, texts on machining metal
>  parts, and so on?

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Tue, 22 Mar 2005 12:39:22 +0000
Date: Tue, 22 Mar 2005 13:39:13 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Joe Abley <[email-masked]>, shim6 <[email-masked]>
Subject: Re: shim - transport/network communication

Joe Abley wrote:
> 
> On 21-Mar-05, at 5:56 PM, Baker Fred wrote:
> 
>> And I worry much about a solution which, for lack of thinking about 
>> such things, picks the worst path simply because it has less AS's in 
>> it or some such thing. We do far too much of that in the Internet.
> 
> 
> In that case we are saying the same thing -- dictating what "best" means 
> (or, from another point of view, considering that there is only one 
> "best" way) is a Bad Idea.
> 

That's why, in the architecture of shim6, IMHO we should clearly
separate the process of choosing the next address pair to use
from the process of actually starting to use those addresses. The
first part (choosing) I would regard as a pluggable component where
implementers will no doubt learn with experience, and probably need
not even be standardized.

    Brian

Delivery-date: Tue, 22 Mar 2005 12:26:44 +0000
Date: Tue, 22 Mar 2005 13:26:13 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Dave Crocker <[email-masked]>, shim6 <[email-masked]>
Subject: Re: charter?

Iljitsch van Beijnum wrote:
> On 21-mrt-05, at 22:50, Dave Crocker wrote:
> 
>> This seems to be the latest:
> 
> 
>>   <http://ops.ietf.org/lists/shim6/msg00009.html>
> 
> 
> Ok. I don't know what kind of moronic software turns a .txt attachment 
> in a .bin one, but that's something for another wg...

I had a config error in my mailer at that time. After a few virus
checkers raised objections, I fixed it :-)

> On the other hand, I don't see how any charter could address the 
> concerns you expressed in your previous message. If the documents are 
> hyperlinked reading the abstracts for each of them is easy enough.

I'm not sure links to I-Ds are such a good idea, but my point, which
Dave chose to ignore, is that I don't know how to boil down all that
work into a paragraph. If someone can do so, I will applaud.

    Brian

Delivery-date: Tue, 22 Mar 2005 11:04:16 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Tue, 22 Mar 2005 13:00:27 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Iljitsch
> Excuse me!?!
> 
> It's you and Avri who keep harping about mobility without addressing 
> the technical issues that I or others bring up in response.
> 
> We now have the situation that a group of people wants to do X. Another 
> group of people wants to do X+Y. Does this mean the first group is now 
> obiligated to do (X+Y), even though (X+Y) is much harder to solve than 
> (X)+(Y)?

I'd even go so far as to say that people want to do X and have the problem
scoped out fairly well (the basic mechanism is somewhat understood, but need
to do the engineering.  With respect to Y, it seems that not everyone is
happy with Y (Mobile IP) would would like to do X+Y' but I don't have
enough to go on to know if Y' is a good idea or not.

Generally, IETF works acceptable on problems with contstrainted scopes;
anything larger starts to resemble design by commitee, meaning the spec
is larger than X+Y but does neither X nor Y acceptably.

I'm sorry to sound so negative, but I am less optimistic about doing
IETF engineering on complex problem spaces that are not fully understood.

John

Delivery-date: Tue, 22 Mar 2005 10:09:45 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Tue, 22 Mar 2005 11:08:46 +0100
To: Dave Crocker <[email-masked]>

On 22-mrt-05, at 3:09, Dave Crocker wrote:

> Take a look at the range of responses the notes from Avri and me and 
> you
> will find that they entirely lack any substance.  They are simply
> dismissive.

Excuse me!?!

It's you and Avri who keep harping about mobility without addressing 
the technical issues that I or others bring up in response.

We now have the situation that a group of people wants to do X. Another 
group of people wants to do X+Y. Does this mean the first group is now 
obiligated to do (X+Y), even though (X+Y) is much harder to solve than 
(X)+(Y)?

Delivery-date: Tue, 22 Mar 2005 05:34:04 +0000
Date: Tue, 22 Mar 2005 07:33:57 +0200
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: charter [Re: how mobile do we want to be]

Erik Nordmark wrote:

>
> But I suspect you'd need a bit more words to say that site multihoming 
> (for the purposes of this charter) is a site which is connected to 
> multiple ISPs and is using multiple PA addresses. The goal is to make 
> communication survive should one or more of the PA addresses become 
> unusable.
>
> We could definitely to some word-smithing on this and put it in the 
> first paragraph of the charter.

This would be useful.

--Jari

Delivery-date: Tue, 22 Mar 2005 02:59:09 +0000
Date: Tue, 22 Mar 2005 12:03:30 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: shim - transport/network communication
Organization: Keio University

On Mon, 21 Mar 2005 07:08:01 -0800
Baker Fred <[email-masked]> wrote:
> In mobility, the counterpart of that issue is in a cell handoff or 
> equivalent. There are of course cases where the device simultaneously 
> loses connectivity one way and regains it another, resulting in a 
> handoff that loses traffic. However, it would be really nice if (as is
>  in fact done in at least some telephone models) in some cases we
>  could 
> presume that the device was reachable by two addresses and could
> advise  its peer that it was in the process of changing. That would
> allow it to  continue to receive on the old address for an interval
> while also being  willing to receive on the new address, and when the
> peer made that  change seeing its data stream change. It would further
> be nice of it  could inject advice to its new router interface (which
> might even be on  the same router) asking that the old address be
> temporarily routed by  the network to that interface, so that even the
> old-address traffic  could find its way to the device subsequent to
> connectivity loss.

When speaking about mobility, if it's about a mobile node operating
Mobile IPv6 or NEMO Basic Support, draft-wakikawa-mobileip-multiplecoa
and other drafts are about giving the possibility to use both interfaces
at the same time. Of course, there are open issues, and we intend to
discuss such issues in the monami6 bof that we want to set up at next
IETF.

Also, we would like the application or the user to be able to choose
which interfaces should be used according to a set of policies.

Thierry

Delivery-date: Tue, 22 Mar 2005 02:10:26 +0000
From: Dave Crocker <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 21 Mar 2005 18:09:44 -0800
Subject: Re: how mobile do we want to be

 On Fri, 18 Mar 2005 22:26:33 +0100, marcelo bagnulo braun wrote:
> >  the history of this line of consideration is that it has pretty much
> >
> >  always excluded any serious effort to integrate mobility and
> >  multihoming. when the initial round of many presentations was done, in
> >  multi6, integration with mobility was automatically deferred to 'some
> >  other group'.
....
>  When we begin discussing these issues in multi6, multiple people
>  claimed that mobility and multihoming are so similar that they could be
>  addressed using similar solutions. Becuase of this reaon, i thourougly
>  studied if mip6 could be used to provide mutlihoming support and the
>  answer is clearly NO. (see draft-bagnulo-multi6-mnm-00.txt)

Marcelo,

As you note, multiple people have considered this topic and, I believe, have 
attempted to consider it carefully.

My comment was about the public (group) process, not the behavior of 
individuals.

We are seeing the fruit of this deficiency in the current public discussion. 

Take a look at the range of responses the notes from Avri and me and you 
will find that they entirely lack any substance.  They are simply 
dismissive.

Had there been serious, public discussion that resulted in serious, public 
understanding and rough consensus about this issue, then the responses would 
have had some substance. 

  d/

ps. on reviewing the document you cite, I note that a) it is tied to MIP6, 
rather than the more general issue I raised, and b) it is a very long way 
from rejecting the reasonableness of combining multihoming with mobility.

  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Tue, 22 Mar 2005 00:11:04 +0000
Cc: shim6 <[email-masked]>, Jeroen Massar <[email-masked]>, Miika Komu <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: shim - transport/network communication
Date: Mon, 21 Mar 2005 19:10:46 -0500
To: Baker Fred <[email-masked]>

On 21-Mar-05, at 5:56 PM, Baker Fred wrote:

> And I worry much about a solution which, for lack of thinking about 
> such things, picks the worst path simply because it has less AS's in 
> it or some such thing. We do far too much of that in the Internet.

In that case we are saying the same thing -- dictating what "best" 
means (or, from another point of view, considering that there is only 
one "best" way) is a Bad Idea.

Joe

Delivery-date: Tue, 22 Mar 2005 00:10:05 +0000
Cc: shim6 <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: shim - transport/network communication
Date: Mon, 21 Mar 2005 19:09:16 -0500
To: Iljitsch van Beijnum <[email-masked]>

On 21-Mar-05, at 5:46 PM, Iljitsch van Beijnum wrote:

> On 21-mrt-05, at 23:35, Joe Abley wrote:
>
>> What about an application that really wants the minimum packet loss, 
>> or the minimum jitter, or the maximum throughput? Or a path where 
>> 80/tcp isn't transparently redirected, or a path with no NAT, or a 
>> path where 161/udp is permitted? How about a path with a path MTU 
>> greater than 1500 bytes?
>
> How exactly does BGP address these needs today?

Let's not re-open that thread.

> ((BTW, my ADSL line meets all these requirements (the 1500+ one only 
> for the first hop, though)))

Unless you are a basement multi-homer, we are talking about different 
things.

>> I would like any new multihoming facility to be
>
> I don't think we should revist the multi6 requirements ordeal.

Me neither. I was trying to illustrate that stepping up from the level 
of details about path selection is more useful.

>> I worry about talk of a multi-homing solution which automatically 
>> chooses "the" best path from a set of candidate paths for all 
>> traffic which flows through an AS.
>
> You're not the only one. Fred explicitly avoided using "the best".

It was the "the" word that concerned me, not the "best" word.

Joe

Delivery-date: Tue, 22 Mar 2005 00:09:03 +0000
Date: Mon, 21 Mar 2005 16:08:12 -0800
From: Erik Nordmark <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: Dave Crocker <[email-masked]>, Margaret Wasserman <[email-masked]>, Brian E Carpenter <[email-masked]>, [email-masked]
Subject: Re: charter [Re: how mobile do we want to be]

Pekka Savola wrote:

> After all, we are not solving "the site multihoming problem" so we don't 
> reference an architecture document -- just one but possibly important 
> subset of it.  Namely, connection survivability across failures when 
> using multiple PA addresses... everything else is bonus.

s/connection/communication/
because I think we intend to take care of "connections" that are 
established after a failure as well "connections" that are in place when 
a failure occurs.

But I suspect you'd need a bit more words to say that site multihoming 
(for the purposes of this charter) is a site which is connected to 
multiple ISPs and is using multiple PA addresses. The goal is to make 
communication survive should one or more of the PA addresses become 
unusable.

We could definitely to some word-smithing on this and put it in the 
first paragraph of the charter.

    Erik

Delivery-date: Mon, 21 Mar 2005 23:22:14 +0000
Date: Mon, 21 Mar 2005 18:21:57 -0500
To: Dave Crocker <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: charter?
Cc: Dave Crocker <[email-masked]>

Hi Dave,

>This seems to be the latest:
>
>   <http://ops.ietf.org/lists/shim6/msg00009.html>

Perhaps we are disagreeing about the charter text because we are 
reading different versions?  I can't read the version in the pointer 
that you sent, as I have no program that understands .bin files. 
However, the latest charter (v4) was actually sent to the list on 
February 18th, and I have included it below for reference.

IMO, the first paragraph does as good a job of describing the scope 
of this WG as the first charter of most IETF WGs.  Do you think that 
we need a more detailed explanation?  If so, what do you think is 
missing.

Margaret

---

Site-multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG. The multi6 WG was tasked with investigating solutions to the site
multihoming problem that will allow the global routing system to
scale. The outcome of the multi6 WG is a specific network-layer shim
architecture for addressing and address handling of sites and
nodes. This includes switching to different locator addresses when
connectivity changes, but without the changes of address being visible
to upper layers, which see a fixed Upper Layer Identifier address
(ULID).

The shim6 WG is to complete this work with the required protocol
developments
and complete the architecture and security analysis of the required
protocols.

The background documents to be considered by the WG include:

   RFC 3582
   draft-ietf-multi6-things-to-think-about-01.txt
   draft-ietf-multi6-multihoming-threats-03.txt

The input documents that the WG will use as the basis for its design
are:

   draft-huston-l3shim-arch-00.txt
   draft-ietf-multi6-functional-dec-00.txt
   draft-ietf-multi6-l3shim-00.txt
   draft-ietf-multi6-failure-detection-00.txt
   draft-ietf-multi6-hba-00.txt
   draft-ietf-multi6-app-refer-00.txt

The shim6 WG is to publish, as standards track RFCs, specifications with
enough details to allow fully interoperable implementations of the
shim layer approach to multihoming as agreed on by the multi6
WG. These implementations will have the ability to take advantage of
multihoming without adding to the growth of the global routing table
by using aggregates already announced by upstream providers.

Since the solution requires state to be maintained at both ends of a
communication, the protocol specification document needs to contain a
state machine description.

Some state transitions may result from external events, however, such
as failure detection rather than from protocol events. These should be
documented in a separate document.

Multihoming is today also often used to achieve various other
features, such as traffic-engineering. The Shim6 WG should document
the use of the shim6 solution in these cases in an applicability
document.

More work items and milestones might need to be added at a later date to
complete all implementation details needed.

In addition to the basic network layer shim solution, the shim6 WG
is specifically chartered to do work on

       o Solutions for site exit router selection that works when each ISP
         uses ingress filtering, i.e. when the chosen site exit needs to
be
         related to the source address chosen by the host. This solution
         should work whether or not the peer site supports the shim6
protocol.

       o Solutions to establish new communications after an outage has
         occurred that does not requires shim support from the
         non-multihomed end of the communication. The wg will explore
         if such solutions are also useful when both ends support the
shim.

       o Congestion control and explore how this and other QoS and
         traffic engineering issues may interact with the use of
         multiple locators at both ends.

       o The relationships between Upper Layer Identifiers (ULIDs)
         and Unique Local Addresses.

       o ICMP error demuxing for locator failure discovery.

       o If necessary, develop and specify formats and structure for

         - Cryptographically protected locators

         - Carrying the flow label across the shim layer
           defined in the multi6 architecture.

The WG will consider whether the proposed model is exposed to
any security threats in addition to those documented in
draft-ietf-multi6-multihoming-threats-03.txt. In any case,
the specifications must specifically refer to all applicable threats
and describe how they are handled,  with the requirement being that
the resulting solution not introduce any threats that make the
security any less than in today's Internet.

The WG will not consider items outside the above scope, such as
interaction with mobility, transport level solutions, or alternative
identifier formats. However, the WG will consider developing methods
for the shim6 level to handle transport layer events (or indicators)
to the shim6 layer as in scope. These events will include any (if at
all) interaction between the application layer and the shim6 layer as
well as documenting what interaction is required between the transport
and the application layer. How various transport layers such as
SCTP and DCCP will handle a scenario with a shim6 layer under it is
not in scope to start with, but should be addressed in a separate
document later. Whether this is a topic for the shim6 WG or a transport
area WG is left for a future IESG decision, once the shim6 solution
has been more worked out.

Milestones

MAY 05    First draft of architectural document
MAY 05 	  First draft of protocol document
MAY 05    First draft on cryptographic locators, if required
MAY 05    First draft on multihoming triggers description
MAY 05 	  First draft on applicability statement document

SEP 05    WG last-call on architectural document
SEP 05	  WG last-call on applicability statement document

NOV 05 	  WG last-call on protocol document
NOV 05    WG last-call on cryptographic locators, if required
NOV 05    Submit completed architectural document to IESG
NOV 05	  Submit applicability statement document to IESG

JAN 06    WG last-call on multihoming triggers description
JAN 06    Submit document on cryptographic locators to the IESG, if
      	  required
JAN 06	  Submit protocol document to the IESG

MAR 06    Submit draft on multihoming triggers description to the IESG

Delivery-date: Mon, 21 Mar 2005 22:57:15 +0000
Cc: "[email-masked]" <[email-masked]>, Jeroen Massar <[email-masked]>, Miika Komu <[email-masked]>
From: Baker Fred <[email-masked]>
Subject: Re: shim - transport/network communication
Date: Mon, 21 Mar 2005 14:56:56 -0800
To: Joe Abley <[email-masked]>

And I worry much about a solution which, for lack of thinking about 
such things, picks the worst path simply because it has less AS's in it 
or some such thing. We do far too much of that in the Internet.

On Mar 21, 2005, at 2:35 PM, Joe Abley wrote:

> Hi Fred,
>
> I am aware that I have much mail to catch up on in this folder, and I 
> may well be missing your point, but this caught my eye:
>
> On 21-Mar-05, at 10:08 AM, Baker Fred wrote:
>
>> I would like the multihoming facility we develop to have the 
>> characteristic of always picking a pair of addresses, and therefore a 
>> route, that gives among the best available RTTs (note I didn't say 
>> "the best"; I want to avoid the worst and accept a reasonable choice) 
>> to the current instantiation of the exchange.
>
> I can think of lots of applications for which that might give the 
> worst possible outcome.
>
> What about an application that really wants the minimum packet loss, 
> or the minimum jitter, or the maximum throughput? Or a path where 
> 80/tcp isn't transparently redirected, or a path with no NAT, or a 
> path where 161/udp is permitted? How about a path with a path MTU 
> greater than 1500 bytes?
>
> I would like any new multihoming facility to be deterministic (so that 
> troubleshooting is possible), tunable (so that the ISP, or the user, 
> or the application, or someone is capable of making reasonable 
> adjustments) and stable (so that positive feedback loops are avoided). 
> This does not necessarily spell "automatic" to me, and I don't think 
> that's necessarily a problem.
>
> I worry about talk of a multi-homing solution which automatically 
> chooses "the" best path from a set of candidate paths for all traffic 
> which flows through an AS.
>
>
> Joe
>

Delivery-date: Mon, 21 Mar 2005 22:46:51 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/network communication
Date: Mon, 21 Mar 2005 23:46:34 +0100
To: Joe Abley <[email-masked]>

On 21-mrt-05, at 23:35, Joe Abley wrote:

> What about an application that really wants the minimum packet loss, 
> or the minimum jitter, or the maximum throughput? Or a path where 
> 80/tcp isn't transparently redirected, or a path with no NAT, or a 
> path where 161/udp is permitted? How about a path with a path MTU 
> greater than 1500 bytes?

How exactly does BGP address these needs today?

(Except by being so complex and expensive that service providers aren't 
about to lose your business by forcing NAT or filtering shenanigans on 
you.)

((BTW, my ADSL line meets all these requirements (the 1500+ one only 
for the first hop, though)))

> I would like any new multihoming facility to be

I don't think we should revist the multi6 requirements ordeal.

> I worry about talk of a multi-homing solution which automatically 
> chooses "the" best path from a set of candidate paths for all traffic 
> which flows through an AS.

You're not the only one. Fred explicitly avoided using "the best".

Delivery-date: Mon, 21 Mar 2005 22:38:16 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: charter?
Date: Mon, 21 Mar 2005 23:37:46 +0100
To: Dave Crocker <[email-masked]>

On 21-mrt-05, at 22:50, Dave Crocker wrote:

> This seems to be the latest:

>   <http://ops.ietf.org/lists/shim6/msg00009.html>

Ok. I don't know what kind of moronic software turns a .txt attachment 
in a .bin one, but that's something for another wg...

I can understand how the introduction in this charter might be seen as 
a tad on the brief side.

On the other hand, I don't see how any charter could address the 
concerns you expressed in your previous message. If the documents are 
hyperlinked reading the abstracts for each of them is easy enough.

Delivery-date: Mon, 21 Mar 2005 22:36:32 +0000
Cc: Miika Komu <[email-masked]>, "[email-masked]" <[email-masked]>, Jeroen Massar <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: shim - transport/network communication
Date: Mon, 21 Mar 2005 17:35:32 -0500
To: Baker Fred <[email-masked]>

Hi Fred,

I am aware that I have much mail to catch up on in this folder, and I 
may well be missing your point, but this caught my eye:

On 21-Mar-05, at 10:08 AM, Baker Fred wrote:

> I would like the multihoming facility we develop to have the 
> characteristic of always picking a pair of addresses, and therefore a 
> route, that gives among the best available RTTs (note I didn't say 
> "the best"; I want to avoid the worst and accept a reasonable choice) 
> to the current instantiation of the exchange.

I can think of lots of applications for which that might give the worst 
possible outcome.

What about an application that really wants the minimum packet loss, or 
the minimum jitter, or the maximum throughput? Or a path where 80/tcp 
isn't transparently redirected, or a path with no NAT, or a path where 
161/udp is permitted? How about a path with a path MTU greater than 
1500 bytes?

I would like any new multihoming facility to be deterministic (so that 
troubleshooting is possible), tunable (so that the ISP, or the user, or 
the application, or someone is capable of making reasonable 
adjustments) and stable (so that positive feedback loops are avoided). 
This does not necessarily spell "automatic" to me, and I don't think 
that's necessarily a problem.

I worry about talk of a multi-homing solution which automatically 
chooses "the" best path from a set of candidate paths for all traffic 
which flows through an AS.

Joe

Delivery-date: Mon, 21 Mar 2005 21:51:09 +0000
From: Dave Crocker <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 21 Mar 2005 13:50:46 -0800
Subject: Re: charter?

 On Mon, 21 Mar 2005 20:23:28 +0100, Iljitsch van Beijnum wrote:
>  After these differences of opinion about the proposed charter I tried
>  to find it... unsuccessfully. What's the location of the proposed
>  charter?

This seems to be the latest:

  <http://ops.ietf.org/lists/shim6/msg00009.html>

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Mon, 21 Mar 2005 21:30:42 +0000
Date: Mon, 21 Mar 2005 13:29:12 -0800
From: Erik Nordmark <[email-masked]>
To: "Bound, Jim" <[email-masked]>
CC: Kurtis Lindqvist <[email-masked]>, Pasi Sarolahti <[email-masked]>, ext Iljitsch van Beijnum <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
Subject: Re: shim - transport/app communication

Bound, Jim wrote:

>>Nobody has proposed changing the IP addresses that are seen 
>>on the wire. 
>>All we are changing is to add a dynamic mapping between what IP 
>>addresses the transport and above sees (the ULIDs) and the IP 
>>addresses 
>>the routing system sees.
> 
> 
> That is not crystal clear to me in the spec above at all.

OK. If you have specific things that are unclear I can make a pass at 
clarifying those in the next rev.

> Something different.  Map an TCP request to an SCTP request as if the
> transport selected was SCTP.

But that has quite more limited applicability than a shim.
First of all, the peer need to do the same (which is also the case for 
the shim) thus you need a very performant approach to failback to using 
TCP when the peer doesn't support this. It is hard for me to see an 
approach using SCTP that can be as efficient as the shim, because the 
shim defers its work thus there is no extra work (state or packets) for 
short-lived connections.
But the SCTP providing the TCP socket API also has the issue that the 
SCTP protocol can't provide the identical service as TCP, with all the 
details of TCP urgent data being the prime example. Even if almost no 
applications use that aspect of TCP, it means that you can't claim 100% 
compatibility for the SCTP approach, whereas the shim can make such a claim.
Finally, SCTP doesn't help for UDP communication.

So while SCTP has many useful features, I don't see it as the ideal fit 
for something that we want to shim in under existing applications and 
have everything work without application changes.
Thus I'm interesting in figuring out how SCTP and the shim can work well 
together for the many cases where SCTP is the right transport protocol 
to use.

>>I'd like to understand why you think a DST option in every packet is 
>>necessary. Such a thing would be complete untrusted.
> 
> 
> Yes the trust would be a problem.  Could be reference to look for ULID new
> extension header then which could be encrypted with IPsec then.  The reason
> to pass the ULIDs is to save processing on each node for mapping to them at
> the transport and above.  This shim now will require a search for ULID on
> every packet. Providing the ULID in the packet avoids that on every system?

If you want intermediaries (middleboxes) to use the ULID, then carrying 
it encrypted doesn't help, since they either don't have the key (hence 
can't decrypt to read the ULID), or they have the key and can spoof the 
ULID and thereby fool the next middle box.

For the endpoint, the processing to lookup the context state and find 
the ULID is quite small, and in the common case of the ULID being the 
same as the locator (which is the case before any failure has happened)
close to zero.
For example, if the shim and no failure happens, the packets would be 
the same as today (IPv6 followed by TCP, for instance) and the shim 
would be close to a no-op. (I say "close to", because the shim might 
want to count the number of packets so that it can determine whether 
this is a long-lived communication i.e. whether it is worth-while to 
establish multi6 state so that the communication can be rehomed should a 
failure occur).
After a failure has occurred and the communication has been rehomed to 
use a different address pair, then the receiver needs to lookup the 
context state and modify the packet before passing it to TCP etc.
That does entail a lookup operation, but depending on details in the 
protocol design it might be possible to have this be just an array 
lookup based on an index in the packet (that's part of what the receive 
side demultiplexing issue is about in the shim draft).

>>Thus it would be 
>>better if middleboxes that want to do verification either
>>  - get explicitly signaled from the endpoints so that they 
>>have the list
>>    of IP addresses
>>  - observe the sim6 signaling protocol and do the same 
>>verification as
>>    the endpoints do as a way to discover the list of IP addresses
>>Both of those can be reasonably secure.
> 
> 
> Yes that is possible but was trying to avoid this and keep e2e only and as
> needed also if they change that can be accomodated too.

Agreed.

I was confused and thought you wanted the DST option for middleboxes and 
not for the endpoints.

    Erik

Delivery-date: Mon, 21 Mar 2005 19:35:58 +0000
Date: Mon, 21 Mar 2005 21:35:33 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Margaret Wasserman <[email-masked]>, Brian E Carpenter <[email-masked]>, [email-masked]
Subject: charter [Re: how mobile do we want to be]

On Mon, 21 Mar 2005, Dave Crocker wrote:
>     "The first
>      paragraph must give a brief summary of the problem area, basis,
>      goal(s) and approach(es) planned for the working group.  This
>      paragraph can be used as an overview of the working group's
>      effort.
>
>      To facilitate evaluation of the intended work and to provide on-
>      going guidance to the working group, the charter must describe the
>      problem being solved and should discuss objectives and expected
>      impact with respect to:..."
>
> Your initial response was that this is a difficult effort to summarize.
> Apparently it does not strike you as boding poorly for the likely outcome of
> this work.  If the charter cannot summarize the problem and the benefit, what
> are the odds that the community is going to be clear about the concrete
> benefits?  For that matter, what is the likelihood that the working group
> participants are going to have rough consensus about the problem, goal, or
> utility?

To me, it doesn't seem to be too difficult to summarize this.  Well, I 
didn't try ;-).

After all, we are not solving "the site multihoming problem" so we 
don't reference an architecture document -- just one but possibly 
important subset of it.  Namely, connection survivability across 
failures when using multiple PA addresses... everything else is bonus.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Mon, 21 Mar 2005 19:23:39 +0000
To: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: charter?
Date: Mon, 21 Mar 2005 20:23:28 +0100

After these differences of opinion about the proposed charter I tried 
to find it... unsuccessfully. What's the location of the proposed 
charter?

Delivery-date: Mon, 21 Mar 2005 19:09:28 +0000
From: Dave Crocker <[email-masked]>
To: Margaret Wasserman <[email-masked]>, Brian E Carpenter <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 21 Mar 2005 11:09:07 -0800
Subject: Re: how mobile do we want to be

 On Mon, 21 Mar 2005 12:48:43 -0500, Margaret Wasserman wrote:
>  I think that the pointers to the goals and architecture documents meet this
>  need.   You apparently don't agree.
>
>  If there is a specific change to the charter that would satisfy your 
concern,
>  please send text.

Margaret,  

What is particularly troubling is to see the cognizant area director and the 
IETF Chair unconcerned about a draft charter that does not satisfy basic IETF 
norms for charters. The current draft makes it impossible for average IETF 
participants to evaluate the proposed work, without their having to explore 
large amounts of text in separate documents that they must separately acquire. 

Even better is that the response to expressions of concern about this is to 
dodge the substance.

My previous notes were quite specific about the deficiencies of the current 
draft and I explained why it is not possible for me to offer corrections. 

Some of my points were quite specific.  You do not respond to them.  

Yet the deficiencies are not minor and are not a matter of subjective 
assessment.  The draft charter simply does not do what is required of it, 
according to existing IETF rules.  Rather than follow your example and leave 
the reference as "existing IETF rules", I will suggest you take a look at 
RFC2418 and specifically Sections 2.1 and 2.2. This aspect of the document 
does notappear to have changed from the original version that Erik Huizer and 
I wrote.  

Since the tone of your responses suggests that you think my concerns represent 
some personal idiosynchracy, please particularly note the following text from 
2.2:

     "The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group.  This
      paragraph can be used as an overview of the working group's
      effort.

      To facilitate evaluation of the intended work and to provide on-
      going guidance to the working group, the charter must describe the
      problem being solved and should discuss objectives and expected
      impact with respect to:..."

Your initial response was that this is a difficult effort to summarize. 
Apparently it does not strike you as boding poorly for the likely outcome of 
this work.  If the charter cannot summarize the problem and the benefit, what 
are the odds that the community is going to be clear about the concrete 
benefits?  For that matter, what is the likelihood that the working group 
participants are going to have rough consensus about the problem, goal, or 
utility?

Your only specific response is that the detailed concerns is to claim that 
they are satisfied by telling the reader of the charter to go look some other 
documents.  So, Margaret, the first question is which ones are those, of the 
set listed in the draft charter?  All of them?  How are we to know?

Let assume that it is only a subset and that they are 
draft-huston-l3shim-arch-00.txt, draft-ietf-multi6-l3shim-00.txt

Taking your specification of the subset "goals and architecure documents", I 
count 17 + 27 pages.  You think it is sufficient to tell someone trying to 
evaluate a charter that they have to go read 44 pages, in order to figure out 
what problem the working group is going to try to solve and what the benefits 
will be after they solve it.  (And I'm not bothering to try to figure out 
whether those documents actually accomplish those goals.)

At some point, the IETF is going to have to return to its original concern 
that its work be useful.  The first step down that path is to ensure that it 
is chartering work for which there is a strong basis, in asserting 
operational relevance. 

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Mon, 21 Mar 2005 17:52:03 +0000
Date: Mon, 21 Mar 2005 12:48:43 -0500
To: Dave Crocker <[email-masked]>, Brian E Carpenter <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: <[email-masked]>, Dave Crocker <[email-masked]>

Hi Dave,

At 1:24 PM -0800 3/20/05, Dave Crocker wrote:
>  On Sun, 20 Mar 2005 09:01:00 +0100, Brian E Carpenter wrote:
>>   see your concern, but it really is complex and I have no idea how it
>>   could be boiled down to a paragraph.
>
>and
>
>On Sun, 20 Mar 2005 08:27:55 -0500, Margaret Wasserman wrote:
>>   This work is a continuation of multiple years of work in the multi6
>>   WG, and I don't think that it is possible (or even makes sense to
>>   try) to boil that knowledge and experience down into a few charter
>>   paragraphs.
>
>
>As I said, it's clear there is a group that holds quite a bit of context. The
>problem is in requiring that all participants (as well as anyone who might
>evaluate the effort) also to have all that context.
>
>A charter specifies a new effort.  It needs to have a meaning explanation of
>the problem and ought to have a meaningful explanation of the intended
>benefit. Who is going to consume the output from the working group and why
>will they want to?

I think that the pointers to the goals and architecture documents meet this
need.   You apparently don't agree.

If there is a specific change to the charter that would satisfy your concern,
please send text.

Margaret

Delivery-date: Mon, 21 Mar 2005 15:08:45 +0000
Cc: "[email-masked]" <[email-masked]>, Jeroen Massar <[email-masked]>
From: Baker Fred <[email-masked]>
Subject: shim - transport/network communication
Date: Mon, 21 Mar 2005 07:08:01 -0800
To: Miika Komu <[email-masked]>

On Mar 19, 2005, at 2:02 PM, Miika Komu wrote:
> Maybe you are referring something similar to [HIP]

I might be; that remains to be shown. The spec you pointed me to, 
unless I missed it, gave me no sense of make-before-break behavior in 
the mobility it discussed, and no sense of route optimization in the 
address management it discussed. Show me those, and I might be in your 
game.

When I talk about these things, I am referring to the fact that the 
shared state in a TCP/SCTP/whatever session includes the current 
address pair - when I send, I send from an address and to an address - 
and the pair of addresses I select determines a number of things about 
the connection. Several years ago, in the context of the IAB, I asked 
Geoff Huston to prototype my concerns here - imagine that a machine 
that he is sitting at in Canberra wants to talk with a machine in 
Singapore that has two addresses and the two addresses have wildly 
different routes which result in dramatic differences in delay. He 
prototyped that by doing a traceroute to two systems there, the .sg 
server and www.singtel.com (IIRC). One gave him a ping RTT of ~100 ms, 
and the other gave him a ping RTT of ~650 ms. The difference was a 
direct route vs a route via the US west coast. In the mobility context, 
a device that is in the process of changing its COA has a similar 
issue, except that one of the addresses suddenly has infinite delay. 
RFC 3704 brings other concerns to the table - ingress filtering by ISPs 
can have truly interesting impacts on the routing of address pairs.

I would like the multihoming facility we develop to have the 
characteristic of always picking a pair of addresses, and therefore a 
route, that gives among the best available RTTs (note I didn't say "the 
best"; I want to avoid the worst and accept a reasonable choice) to the 
current instantiation of the exchange.

A simple way to prototype this in a wired network is this. If two 
machines A and B each have sets of addresses A' and B', then the set of 
routes between them is characterized by the cross product of those 
sets. A TCP could send a SYN on each address pair and ACK the first 
SYN-ACK it gets back, RST'ing the rest. This may not be the best route 
long term, but it will be a reasonable one in the near term. There are 
thoughts that come to mind quickly on scaling features of the approach 
(the net already is ~40% TCP control traffic, so I'm told), but as a 
benchmark of a simple way to calculate a reasonable result, it's not 
all bad. I would like the algorithm we use to generate at least as 
reasonable a route.

I find myself wondering whether we could use something akin to an 
ICMPv6 Route Redirect to ask the network to cache such disparities and 
advise a host of a superior next hop and address pair to use at the 
network layer when instantiating a host-host exchange...

In mobility, the counterpart of that issue is in a cell handoff or 
equivalent. There are of course cases where the device simultaneously 
loses connectivity one way and regains it another, resulting in a 
handoff that loses traffic. However, it would be really nice if (as is 
in fact done in at least some telephone models) in some cases we could 
presume that the device was reachable by two addresses and could advise 
its peer that it was in the process of changing. That would allow it to 
continue to receive on the old address for an interval while also being 
willing to receive on the new address, and when the peer made that 
change seeing its data stream change. It would further be nice of it 
could inject advice to its new router interface (which might even be on 
the same router) asking that the old address be temporarily routed by 
the network to that interface, so that even the old-address traffic 
could find its way to the device subsequent to connectivity loss.

I realize I'm asking a lot.

But I don't, I really don't, want the application to have to know 
ANYTHING about that...

Delivery-date: Mon, 21 Mar 2005 12:46:27 +0000
Date: Mon, 21 Mar 2005 13:45:51 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Margaret Wasserman <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Margaret Wasserman wrote:
...
> I do have one concern about this part of the charter -- it cites I-Ds, 
> and I am not sure that all of those I-Ds will eventually be published as 
> RFCs in their current form.  Kurtis, Geoff and Brian -- which of the 
> I-Ds cited in the charter have been submitted to the IESG for 
> publication?  What should we do with the others?  Are they expected to 
> be updated over time, or will their mention here limit the useful 
> lifetime of this charter to <6 months?

  draft-ietf-multi6-things-to-think-about-01.txt
   Approved - in RFC queue
  draft-ietf-multi6-multihoming-threats-03.txt
   In IESG Evaluation

  draft-huston-l3shim-arch-00.txt
  draft-ietf-multi6-functional-dec-00.txt
  draft-ietf-multi6-l3shim-00.txt
  draft-ietf-multi6-failure-detection-00.txt
  draft-ietf-multi6-hba-00.txt
  draft-ietf-multi6-app-refer-00.txt
   These are not ready for the IESG.
   The plan is that the new WG will inherit them and do what it wants with
   them; so indeed the charter would need (trivial) updating in about 6 months.

      Brian

Delivery-date: Sun, 20 Mar 2005 14:31:36 +0000
Subject: Re: shim - transport/app communication
From: Jeroen Massar <[email-masked]>
To: Baker Fred <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Sun, 20 Mar 2005 15:30:56 +0100

--=-QLbmH2HIaVwGNudg2BSl
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2005-03-19 at 13:32 -0800, Baker Fred wrote:
>On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
>> the only thing an application should depend on here is that it 
>> supports IPv6 addresses
>
>If I could make a humble request here...
>
>Could we please manage to avoid the worst of the layering faults we 
>committed in the IPv4 Internet? The thing that has made NAT hard and 
>made applications break crossing a NAT was that the applications know 
>something about addresses. Let's not do that with IPv6 applications.
>
>Applications should know about names and APIs, period. They should open 
>a socket-or-whatever to a name, and accept that the service underneath 
>gets them to an instantiation of it.

Full ack, please cast it in gold. Applications should of course use
getaddrinfo(), inet_ntop() and inet_pton() where needed.

I am one of the strong proponents of it and usually refer folks who ask
how to support IPv6 to Eva Castro's document:
http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html
Or Itojun's paper at: http://www.kame.net/newsletter/19980604/

With the above I only meant that the app should minimaly be able to do
IPv6 addresses, with IPv4 most likely not supporting shim6 for this
setup. And as a consequence of 'app supporting IPv6' I also mean that
they should be using getaddrinfo().

<SNIP>
>But please-please-please can we have the applications treat that as an 
>opaque character string that could just as easily contain directions to 
>the donut store?

I fully agree, give me donuts be they IPv4 or IPv6 or IPv9 ;)

Greets,
 Jeroen

--=-QLbmH2HIaVwGNudg2BSl
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-QLbmH2HIaVwGNudg2BSl--

Delivery-date: Sun, 20 Mar 2005 13:28:40 +0000
Date: Sun, 20 Mar 2005 08:27:55 -0500
To: Dave Crocker <[email-masked]>, Brian E Carpenter <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: <[email-masked]>, Dave Crocker <[email-masked]>

Hi Dave,

At 9:14 PM -0800 3/19/05, Dave Crocker wrote:
>the draft charter is primarily notable for its lack of explanation. 
>it does not explain what the problem is, other than to reference 
>"site multihoming" and does not explain the solution path, other 
>than to say that it will be whatever was under discussion earlier 
>and elsewhere.
>
>please imagine being new to the topic and trying to read the 
>charter, to understand what the actual problem is and what the 
>benefits of the solution will be.  you will find none of this 
>discussed in the draft charter.

This work is a continuation of multiple years of work in the multi6 
WG, and I don't think that it is possible (or even makes sense to 
try) to boil that knowledge and experience down into a few charter 
paragraphs.

The proposed charter states that it is a continuation of the multi6 
work and cites 9 documents that a person new to this topic should 
read to understand the context of the discussion, including:  a 
multihoming goals document, a threat analysis, an architectural 
framework and the latest design team output regarding the solution 
space.  In my personal opinion, this is much more detailed 
information that we usually have when we start a WG, and would do 
more to help a new person come up-to-speed in this area than the 
typical IETF WG charter.

I do have one concern about this part of the charter -- it cites 
I-Ds, and I am not sure that all of those I-Ds will eventually be 
published as RFCs in their current form.  Kurtis, Geoff and Brian -- 
which of the I-Ds cited in the charter have been submitted to the 
IESG for publication?  What should we do with the others?  Are they 
expected to be updated over time, or will their mention here limit 
the useful lifetime of this charter to <6 months?

Margaret

Delivery-date: Sun, 20 Mar 2005 09:02:00 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Sun, 20 Mar 2005 10:00:28 +0100
To: Baker Fred <[email-masked]>

On 19-mrt-05, at 22:32, Baker Fred wrote:

>> the only thing an application should depend on here is that it 
>> supports IPv6 addresses

> If I could make a humble request here...

> Could we please manage to avoid the worst of the layering faults we 
> committed in the IPv4 Internet? The thing that has made NAT hard and 
> made applications break crossing a NAT was that the applications know 
> something about addresses. Let's not do that with IPv6 applications.

It's already done. The RFC 3493 API extensions require an application 
to know about IPv6, if only because they have to specify AF_INET6. In 
theory, that's it, but in practice it's much worse because an IPv6 
application really needs to cycle through all available addresses, 
which IPv4 applications rarely do. Then there is the whole IPv4-mapped 
implementation debacle that makes writing (portable) applications that 
support both IPv4 and IPv6 rather tricky.

The only real solution that I can see here is yet another API that 
moves address resolution out of the application, and completely hides 
the IP version from the application.

The good news is that there should be some time to get it right before 
we need to move to whatever comes after IPv6.  :-)

Delivery-date: Sun, 20 Mar 2005 08:01:12 +0000
Date: Sun, 20 Mar 2005 09:01:00 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dave Crocker <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Dave Crocker wrote:
...
> the draft charter is primarily notable for its lack of explanation.  it does not explain what the problem is, other than to reference "site multihoming" and does not explain the solution path, other than to say that it will be whatever was under discussion earlier and elsewhere.

I see your concern, but it really is complex and I have no idea how it
could be boiled down to a paragraph.

The draft explicitly cites the multi6 output documents where these
issues are fully explored. We can't incorporate that mass of work
in the charter.

    Brian

Delivery-date: Sun, 20 Mar 2005 07:55:30 +0000
Date: Sun, 20 Mar 2005 08:55:03 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Baker Fred <[email-masked]>
CC: [email-masked]
Subject: Re: shim - transport/app communication

Fred,

Baker Fred wrote:
> On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
> 
>> the only thing an application should depend on here is that it 
>> supports IPv6 addresses
> 
> 
> If I could make a humble request here...
> 
> Could we please manage to avoid the worst of the layering faults we 
> committed in the IPv4 Internet? The thing that has made NAT hard and 
> made applications break crossing a NAT was that the applications know 
> something about addresses. Let's not do that with IPv6 applications.
> 
> Applications should know about names and APIs, period. They should open 
> a socket-or-whatever to a name, and accept that the service underneath 
> gets them to an instantiation of it.

It gets a bit more complex with multi-party referrals, but basically,
yes.

All this is why we have draft-ietf-multi6-app-refer-00.txt as
input from multi6 to shim6. Maybe people should send suggestions
to its author?

    Brian
> 
> I don't object to having a service layer API produce a text string 
> relating to the address-instantiation that it is currently using for a 
> name, a text string that would contain a human-readable address, for 
> placement in a log message or an SMTP history line. But 
> please-please-please can we have the applications treat that as an 
> opaque character string that could just as easily contain directions to 
> the donut store?
> 

Delivery-date: Sun, 20 Mar 2005 05:14:43 +0000
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 19 Mar 2005 21:14:37 -0800
Subject: Re: how mobile do we want to be

 On Fri, 18 Mar 2005 18:40:32 +0100, Brian E Carpenter wrote:
>  I don't believe we have any chance
>  of rapid success unless we tackle a finite and well understood
>  problem.

i concur.

>  The general issues of mobility are currently arousing some
>  interest in the IAB, which seems the right place.

i can't imagine how or why.  the iab does not produce engineering solutions. 

>  I don't, however, believe that shim6 does any harm to
>  mobility, and ensuring that property is in scope, of course.

i am trying to guess the basis for such a claim. my guess is that there is a collection of folk who think they understand such details, but i'm hard-pressed to think of where any of this is documented, and thereby subject to objective, external evaluation. 

this topic has been under discussion for a very long time.  that makes it easy to think that issues have been dealt with, even when they haven't. 

the draft charter is primarily notable for its lack of explanation.  it does not explain what the problem is, other than to reference "site multihoming" and does not explain the solution path, other than to say that it will be whatever was under discussion earlier and elsewhere.

please imagine being new to the topic and trying to read the charter, to understand what the actual problem is and what the benefits of the solution will be.  you will find none of this discussed in the draft charter.

you might note that i am not proffering suggested texts or approaches. if and when the group shows some interested in that discussion, i'll be glad to participate.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Sat, 19 Mar 2005 22:02:51 +0000
Date: Sun, 20 Mar 2005 00:02:37 +0200 (EET)
From: Miika Komu <[email-masked]>
To: Baker Fred <[email-masked]>
Cc: Jeroen Massar <[email-masked]>, [email-masked]
Subject: Re: shim - transport/app communication

On Sat, 19 Mar 2005, Baker Fred wrote:

> On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
> > the only thing an application should depend on here is that it
> > supports IPv6 addresses
>
> If I could make a humble request here...
>
> Could we please manage to avoid the worst of the layering faults we
> committed in the IPv4 Internet? The thing that has made NAT hard and
> made applications break crossing a NAT was that the applications know
> something about addresses. Let's not do that with IPv6 applications.
>
> Applications should know about names and APIs, period. They should open
> a socket-or-whatever to a name, and accept that the service underneath
> gets them to an instantiation of it.

Maybe you are referring something similar to this:

  http://www.iki.fi/miika/docs/draft-mkomu-hip-native-api-00-pre1.txt

or the longer version:

  http://hipl.hiit.fi/hipl/hip-native-api-final.pdf

(but then you actually need to modify applications, which I think you
don't want to do in the multi6 working group)

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

Delivery-date: Sat, 19 Mar 2005 21:33:06 +0000
Cc: [email-masked]
From: Baker Fred <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Sat, 19 Mar 2005 13:32:35 -0800
To: Jeroen Massar <[email-masked]>

On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
> the only thing an application should depend on here is that it 
> supports IPv6 addresses

If I could make a humble request here...

Could we please manage to avoid the worst of the layering faults we 
committed in the IPv4 Internet? The thing that has made NAT hard and 
made applications break crossing a NAT was that the applications know 
something about addresses. Let's not do that with IPv6 applications.

Applications should know about names and APIs, period. They should open 
a socket-or-whatever to a name, and accept that the service underneath 
gets them to an instantiation of it.

I don't object to having a service layer API produce a text string 
relating to the address-instantiation that it is currently using for a 
name, a text string that would contain a human-readable address, for 
placement in a log message or an SMTP history line. But 
please-please-please can we have the applications treat that as an 
opaque character string that could just as easily contain directions to 
the donut store?

Delivery-date: Sat, 19 Mar 2005 15:41:34 +0000
From: [email-masked]
Subject: Re: how mobile do we want to be
Date: Sat, 19 Mar 2005 10:41:05 -0500
To: shim6 <[email-masked]>

On 18 mar 2005, at 07.24, Brian E Carpenter wrote:

> Thierry Ernst wrote:
>> On Fri, 18 Mar 2005 11:12:02 +0100
>> Brian E Carpenter <[email-masked]> wrote:
>>>> So please let's do this shim in peace and revisit the interaction
>>>> with  other stuff when there is something concrete to build on.

I persist in believing that will be too late.  And of course if the 
charter is approved with the exclusion of mobility as a legitimate 
concern, anyone who cares about the implications of the edge in motion 
will be excluded from voicing these concerns.

>>>
>>> Yes, that was the clear consensus of the multi6 discussion
>>> and that's why the shim6 draft charter is the way it is. I see
>>> no value in restarting that debate.
>> Would you explain me what is the purpose of a BOF if you exclude
>> discussions ? Just don't do BOF and straight approve the WG then.
>
> We didn't exclude the discussion. I'm just stating it as my
> opinion that the draft charter is correct on this point, and that
> this was already clear in the multi6 discussions.

Yes, that is because Mobility of any sort  was out of scope in Multi6, 
and that is what I am hoping can be avoided in the chartering of this 
group.

This is a new effort, and while the recommendations of Multi6 should 
certainly be considered strongly, I don't see how they can be the 
_only_ determinant on this charter.

I think the input from the BoF of several people and the support for 
some sort of inclusion of mobility from the participants of this list 
should force consideration of our concerns.  I do not see that there is 
consensus for excluding these considerations, not that consensus, even 
rough consensus, is necessarily the primary determinant in chartering 
decisions.

There seems to be a fundamental disagreement between those of us who 
believe the topics are intricately related and thus who argue they are 
not.  I don't think this can be resolved in a shouting match, claims of 
having learned nothing new or accusations of IETF end runs but needs to 
be dealt with by an engineering analysis by a design team.  And I think 
this design team should be part of the chartered work of shim6, should 
be permitted to speak on their issues in the WG and should have the 
analysis listed among the WG's milestones.

I do NOT think the work of developing an architecture should wait for 
the results of this study, but believe they should be parallel efforts 
so that the architecture can be looked at with the results of the 
analysis before proceeding on to protocol development.

a.

Delivery-date: Sat, 19 Mar 2005 04:26:06 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Fri, 18 Mar 2005 23:26:01 -0500
From: "Bound, Jim" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "Ryuji Wakikawa" <[email-masked]>, "Margaret Wasserman" <[email-masked]>
Cc: "Thierry Ernst" <[email-masked]>, <[email-masked]>

whoops.  Good point.  We are still ad hoc?  
thanks
/jim 

> -----Original Message-----
> From: Geoff Huston [mailto:[email-masked]] 
> Sent: Friday, March 18, 2005 4:31 PM
> To: Bound, Jim; Ryuji Wakikawa; Margaret Wasserman
> Cc: Thierry Ernst; [email-masked]
> Subject: RE: how mobile do we want to be
> 
> 
> >P.S. Chairs I believe there is consensus we are to focus on 
> multihoming
> >and not mobility.  If I am correct my input is for you to 
> shut down this
> >discussion and many mails that are doing nothing to further 
> the delivery
> >of a multihoming solution.  But I will continue as above to discuss
> >interesting points raised that are clear technically and 
> worth my tiime.
> >thanks
> 
> 
> 
> Until we have a charter passed by the IESG I believe that there is no 
> working group per se, and the question of chair action is 
> perhaps a little 
> premature.
> 
> However... Speaking personally I agree with your proposition, 
> in that I 
> observe that this discussion has not exposed to me any new 
> arguments that 
> were not exhaustively covered in the multi6 stream, and I can 
> sympathize 
> with a perspective that the constant repetition of calls to 
> broaden the 
> scope of this effort is at best distracting to the shim6 
> effort. It's my 
> personal view that there is merit in focussing the shim6 
> effort at a clean 
> and consistent specification of the shim6 approach, and in 
> that there is 
> enough material in that alone to keep any working group productively 
> engaged for a suitable amount of time.
> 
> That does not imply that the general architectural approach 
> of splitting 
> the semantics of an end point identifier and network-based 
> locators does 
> not have a rich well of topics  from which to draw from. On 
> the contrary, 
> as many groups in the past have already discovered, there is 
> almost an 
> endless stream of interesting, challenging and provocative areas of 
> consideration within this generic topic area, and there will 
> always be folk 
> who would like to bite off the entire space and see if some 
> solutions can 
> be engineered that attempt to cover the entire spectrum of 
> potential that 
> is offered if one can assume some level of independence of these two 
> identification spaces. But that is not where I personally  
> thought shim6 is 
> headed, and to me this shim6 effort is a focussed activity 
> that looks for a 
> decent solution within one aspect of an admitted broader area 
> of potential 
> activity.
> 
> It may be that the level of interest in this split endpoint 
> identifier 
> network location identifier space is an indicator that the 
> time has come 
> that there is once more a sufficiently large pool of 
> interested folk who 
> may wish to resume the Name Space Research Group efforts (!) . 
> Indeed,  they may well be in a position to put a decent case 
> to the irtf 
> chair  for the (re)formation of a research group on this topic. 
> That  possible direction for this general consideration is, 
> once again, 
> well beyond a sensible focus for the ietf's shim6 effort, in my view.
> 
> regards,
> 
>     Geoff
> 
> 
> 
> 
> 
> 

Delivery-date: Sat, 19 Mar 2005 04:21:43 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Fri, 18 Mar 2005 23:20:55 -0500
From: "Bound, Jim" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Kurtis Lindqvist" <[email-masked]>, "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>, "Leif Johansson" <[email-masked]>, <[email-masked]>

> Bound, Jim wrote:
> 
> > Yes and what must be on the wire are valid IP addresses in 
> the header.  As
> > we don't know what these will look like and how they are to 
> be managed it is
> > uclear and not your shim spec draft-ietf-multi6-l3shim-00.txt.
> 
> Nobody has proposed changing the IP addresses that are seen 
> on the wire. 
> All we are changing is to add a dynamic mapping between what IP 
> addresses the transport and above sees (the ULIDs) and the IP 
> addresses 
> the routing system sees.

That is not crystal clear to me in the spec above at all.

> 
> >  Add network
> > management to that etc.  The point is that multihoming 
> architecture should
> > solve that specific set of problems not cause any change to 
> the rest of the
> > network operational infrastructure.  That is why I still 
> believe SCTP is the
> > correct approach by adding ULID extensions, we are 
> reinventing the wheel.
> > The engineering cost and time to market for implementation 
> will be faster if
> > we use SCTP and build TCP shims for multihoming. 
> 
> You mean carry TCP (and UDP?) over SCTP, or something different?

Something different.  Map an TCP request to an SCTP request as if the
transport selected was SCTP.

> 
> > And we can meet a
> > reasonable time to market product set introduction.  The 
> ULID for the wire
> > should be carried as a DST Option. 
> 
> I'd like to understand why you think a DST option in every packet is 
> necessary. Such a thing would be complete untrusted.

Yes the trust would be a problem.  Could be reference to look for ULID
new extension header then which could be encrypted with IPsec then.  The
reason to pass the ULIDs is to save processing on each node for mapping
to them at the transport and above.  This shim now will require a search
for ULID on every packet. Providing the ULID in the packet avoids that
on every system?

> Thus it would be 
> better if middleboxes that want to do verification either
>   - get explicitly signaled from the endpoints so that they 
> have the list
>     of IP addresses
>   - observe the sim6 signaling protocol and do the same 
> verification as
>     the endpoints do as a way to discover the list of IP addresses
> Both of those can be reasonably secure.

Yes that is possible but was trying to avoid this and keep e2e only and
as needed also if they change that can be accomodated too.

> 
> > I will wait for your next spec to comment
> > on how this can be done and slight changes to some of the 
> diagrams in the
> > spec.  But figure your putting out a new spec soon on that 
> now, if not I can
> > send you offline comments.  This effort should not impact 
> the rest of the
> > Internet network implementations or it will never happen. 
> 
> I agree it shouldn't impact the rest of the Internet.
> 
> 
> > Yes you discuss this in the draft above and left it that 
> this may have other
> > problems.  I agree. But to my point above the multihoming 
> solution should
> > not have to cause "signaling protocols" to change.  That is 
> my concern and
> > most of my concerns are take care of if the src and dst 
> addresses are IPv6
> > addresses and only them in the header when entering the wire.
> 
> I don't think "signaling protocols" need to change more than 
> they need 
> to change to support SCTP (and in both cases this might be a host 
> implementation issue and not a protocol standard issue).
> Suppose that one is using RSVP to setup reservations for some 
> IP address 
> pair and port number pair. If the IP addresses change, whether it is 
> SCTP or the shim that does such a change, you'd want to do something 
> with the RSVP reservation (either change it to include all 
> the addresses 
> that are used, or change it to use the new addresses).

Forget my comment I wanted to be sure IP addresses were being used.  

> 
> So I think this level of change is inherest in the problem of 
> wanting to 
> switch the IP addresses to have the communication survive, and 
> indepedent of the layer in the stack where we add the address agility.

I agree as long as the wire is IPv6 address format compliant etc.

thanks
/jim

> 
>     Erik
> 

Delivery-date: Fri, 18 Mar 2005 21:49:44 +0000
Cc: Thierry Ernst <[email-masked]>, Margaret Wasserman <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 22:42:37 +0100
To: Ryuji Wakikawa <[email-masked]>

Hi Ryuji,

El 18/03/2005, a las 19:43, Ryuji Wakikawa escribió:

> Hello Margaret
>
> I just subscribed to list and may miss some background of this 
> discussion.
> some comments.
>
> On 2005/03/19, at 1:56, Margaret Wasserman wrote:
>
>>
>> Hi Thierry,
>>
>>> Another one is saying that "initially the WG will focus only on site
>>> multihoming" but "will later investigate the impact on exisiting
>>> protocols, particularly mobility related ones such as MIPv6, NEMO,
>>> FMIPv6, HMIPv6".
>>
>> I would actually be bit stronger than this and say that the intiial 
>> shim6 work should have a goal of being compatible with existing 
>> mobility solutions, such as MIP6 and NEMO.  I think that we should 
>> take a similar goal regarding transport protocols, such as TCP, UDP 
>> and SCTP.
>> It might (or might not) be the subject of later work to optimize the 
>> interactions between shim6 and MIP6 and/or to develop new mobility 
>> solutions based on shim6.
>
> Interactions between shim6 and MIP6 are necessary, when SHIM6 becomes 
> RFC.
> BUT, SHIM6 should not be solo solution to achieve end/site multihoming.
>
> Indeed, it's also important to look at possible multihoming solutions 
> for
> MIP6 or NEMO protocol in "other" WG, maybe MIP6, Monami, NEMO.
>
> Since SHIM6 and MIP6/NEMO are very similar design concept (to me),
> it indicates that MIP6/NEMO are also capability to support 
> site/end-multihoming by itself.
>

I don't think this is possible
we have already being there in multi6 and the conclusion is that this 
is simply not possible with current MIP spec
Please read draft-bagnulo-multi6-mnm-00.txt

Regards, marcelo

> MIP6 already has a unique address (HoA),
> It's not big changes to MIP6 to bind multiple CoAs to the HoA. It's 
> same for MR, too.
>
> regards,
> ryuji
>
>
>
>

Delivery-date: Fri, 18 Mar 2005 21:49:43 +0000
Cc: <[email-masked]>, Thierry Ernst <[email-masked]>, Brian E Carpenter <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 22:26:33 +0100
To: Dave Crocker <[email-masked]>

Hi Dave,

El 18/03/2005, a las 16:59, Dave Crocker escribió:

>  On Fri, 18 Mar 2005 13:24:46 +0100, Brian E Carpenter wrote:
>>   We didn't exclude the discussion. I'm just stating it as my
>>   opinion that the draft charter is correct on this point, and that
>>   this was already clear in the multi6 discussions.
>
> the history of this line of consideration is that it has pretty much 
> always excluded any serious effort to integrate mobility and 
> multihoming. when the initial round of many presentations was done, in 
> multi6, integration with mobility was automatically deferred to 'some 
> other group'.
>

I am sorry but i disagree with you in this point.

When we begin discussing these issues in multi6, multiple people 
claimed that mobility and multihoming are so similar that they could be 
addressed using similar solutions. Becuase of this reaon, i thourougly 
studied if mip6 could be used to provide mutlihoming support and the 
answer is clearly NO. (see draft-bagnulo-multi6-mnm-00.txt)

so i must disagree with your view of the history of the multi6 here. 
The interaction of mobility techniques and multihoming was discussed 
and presented in multi wg. The problem is that mobilit techniqques are 
simply unable to provide multihoming support.

The reason for this is clear. In multihoming, it is necesarry to 
support the fact that some addresses are unreachable. However, in mip, 
they made the assumption that the home address is always reachable.

> in case no one has noticed, responses to efforts at pursuing such an 
> integration discussion have pretty much always tended to be similar to 
> the responses appearing on this thread.  those responses are automatic 
> rejection, without any interest in seeing whether integration really 
> can make sense. in other words, the tone of this online discussion has 
> had more to do with religion than analysis.
>

I am sorry but imho this is not the case. As mentioned earlier, a 
pretty complete analysis was done w.r.t. these issues and the 
conclusion was rejecting this approach.

Regards, marcelo

> my original posting, here, was attempting to compare this choice to a 
> decision to have tcp behave very differently in lans than in wans -- 
> in other words, to have two different tcps.  the response, here, has 
> been the equivalent of "lans are different from wans, so it's fine to 
> have a different solution for tcp."
>
> it is certainly true that some definitions of mobility and some 
> definitions of multihoming can permit no useful overlap in the 
> technical solution.
>
> however it is also true that that some definitions permit a very high 
> degree of overlap.  folks seem curiously uninterested in being clear 
> about the reasons for choosing the former, rather than the latter, 
> given the serious long-term costs of having different solutions.
>
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
>
>

Delivery-date: Fri, 18 Mar 2005 21:49:42 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 22:41:00 +0100
To: Thierry Ernst <[email-masked]>

Hi Thierry,

El 18/03/2005, a las 10:03, Thierry Ernst escribió:
> Note - I'm repeating myself - than I don't say I oppose a WG, but:
>
> - I think experimental RFC would make better sense than draft standards
> (this would give room to work on a focused topic without risk such an
> architectural change is deployed without considering mobility; at
> the same time this would allow time for other researching on the
> mobility aspects so that draft standards are produced when the question
> has been fully pondered.
>

I don't think we have time for exprimental RFc here. Multihoming is a 
very real problem today. We need to provide a solution a couple of 
years ago. The risk of not doing so is becoming too high. For instance 
see the policy proposal for PI allocations in the ARIn region. the 
community will not wait anymore for us discussing and expremineting, 
they will strat assigning PI addresses and blow the bgp table.

For this reason, we need to deliver a standard tracks multihoming 
solution ASAP.

regards, marcelo

>   => I would like to make sure this point is discussed when the WG is 
> to
> be approved/disapproved.
>
> - a twin IRTF work would be nice to look into the wider aspects such as
> mobility
>
> - a word saying that the WG will focus on the sole site
> multihoming aspect initially, but that it will consider mobility
> later
>
> - a word saying that the shim6 solution must make sure other standards
> such as MIP6, NEMO can work unchanged (no hurt - this was seconded by
> other people on this thread and at the BOF): this implies an analysis
> document.
>
> Thierry
>
>
>
>

Delivery-date: Fri, 18 Mar 2005 21:31:27 +0000
Date: Sat, 19 Mar 2005 08:31:01 +1100
To: "Bound, Jim" <[email-masked]>, "Ryuji Wakikawa" <[email-masked]>, "Margaret Wasserman" <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: RE: how mobile do we want to be
Cc: "Thierry Ernst" <[email-masked]>, <[email-masked]>

>P.S. Chairs I believe there is consensus we are to focus on multihoming
>and not mobility.  If I am correct my input is for you to shut down this
>discussion and many mails that are doing nothing to further the delivery
>of a multihoming solution.  But I will continue as above to discuss
>interesting points raised that are clear technically and worth my tiime.
>thanks

Until we have a charter passed by the IESG I believe that there is no 
working group per se, and the question of chair action is perhaps a little 
premature.

However... Speaking personally I agree with your proposition, in that I 
observe that this discussion has not exposed to me any new arguments that 
were not exhaustively covered in the multi6 stream, and I can sympathize 
with a perspective that the constant repetition of calls to broaden the 
scope of this effort is at best distracting to the shim6 effort. It's my 
personal view that there is merit in focussing the shim6 effort at a clean 
and consistent specification of the shim6 approach, and in that there is 
enough material in that alone to keep any working group productively 
engaged for a suitable amount of time.

That does not imply that the general architectural approach of splitting 
the semantics of an end point identifier and network-based locators does 
not have a rich well of topics  from which to draw from. On the contrary, 
as many groups in the past have already discovered, there is almost an 
endless stream of interesting, challenging and provocative areas of 
consideration within this generic topic area, and there will always be folk 
who would like to bite off the entire space and see if some solutions can 
be engineered that attempt to cover the entire spectrum of potential that 
is offered if one can assume some level of independence of these two 
identification spaces. But that is not where I personally  thought shim6 is 
headed, and to me this shim6 effort is a focussed activity that looks for a 
decent solution within one aspect of an admitted broader area of potential 
activity.

It may be that the level of interest in this split endpoint identifier 
network location identifier space is an indicator that the time has come 
that there is once more a sufficiently large pool of interested folk who 
may wish to resume the Name Space Research Group efforts (!) . 
Indeed,  they may well be in a position to put a decent case to the irtf 
chair  for the (re)formation of a research group on this topic. 
That  possible direction for this general consideration is, once again, 
well beyond a sensible focus for the ietf's shim6 effort, in my view.

regards,

    Geoff

Delivery-date: Fri, 18 Mar 2005 20:25:54 +0000
Date: Fri, 18 Mar 2005 12:25:06 -0800
From: Erik Nordmark <[email-masked]>
To: "Bound, Jim" <[email-masked]>
CC: Kurtis Lindqvist <[email-masked]>, Pasi Sarolahti <[email-masked]>, ext Iljitsch van Beijnum <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
Subject: Re: shim - transport/app communication

Bound, Jim wrote:

> Yes and what must be on the wire are valid IP addresses in the header.  As
> we don't know what these will look like and how they are to be managed it is
> uclear and not your shim spec draft-ietf-multi6-l3shim-00.txt.

Nobody has proposed changing the IP addresses that are seen on the wire. 
All we are changing is to add a dynamic mapping between what IP 
addresses the transport and above sees (the ULIDs) and the IP addresses 
the routing system sees.

>  Add network
> management to that etc.  The point is that multihoming architecture should
> solve that specific set of problems not cause any change to the rest of the
> network operational infrastructure.  That is why I still believe SCTP is the
> correct approach by adding ULID extensions, we are reinventing the wheel.
> The engineering cost and time to market for implementation will be faster if
> we use SCTP and build TCP shims for multihoming. 

You mean carry TCP (and UDP?) over SCTP, or something different?

> And we can meet a
> reasonable time to market product set introduction.  The ULID for the wire
> should be carried as a DST Option. 

I'd like to understand why you think a DST option in every packet is 
necessary. Such a thing would be complete untrusted. Thus it would be 
better if middleboxes that want to do verification either
  - get explicitly signaled from the endpoints so that they have the list
    of IP addresses
  - observe the sim6 signaling protocol and do the same verification as
    the endpoints do as a way to discover the list of IP addresses
Both of those can be reasonably secure.

> I will wait for your next spec to comment
> on how this can be done and slight changes to some of the diagrams in the
> spec.  But figure your putting out a new spec soon on that now, if not I can
> send you offline comments.  This effort should not impact the rest of the
> Internet network implementations or it will never happen. 

I agree it shouldn't impact the rest of the Internet.

> Yes you discuss this in the draft above and left it that this may have other
> problems.  I agree. But to my point above the multihoming solution should
> not have to cause "signaling protocols" to change.  That is my concern and
> most of my concerns are take care of if the src and dst addresses are IPv6
> addresses and only them in the header when entering the wire.

I don't think "signaling protocols" need to change more than they need 
to change to support SCTP (and in both cases this might be a host 
implementation issue and not a protocol standard issue).
Suppose that one is using RSVP to setup reservations for some IP address 
pair and port number pair. If the IP addresses change, whether it is 
SCTP or the shim that does such a change, you'd want to do something 
with the RSVP reservation (either change it to include all the addresses 
that are used, or change it to use the new addresses).

So I think this level of change is inherest in the problem of wanting to 
switch the IP addresses to have the communication survive, and 
indepedent of the layer in the stack where we add the address agility.

    Erik

Delivery-date: Fri, 18 Mar 2005 20:12:59 +0000
Date: Fri, 18 Mar 2005 12:12:34 -0800
From: Erik Nordmark <[email-masked]>
To: Margaret Wasserman <[email-masked]>
CC: Thierry Ernst <[email-masked]>, [email-masked]
Subject: Re: how mobile do we want to be

Margaret Wasserman wrote:

> I would actually be bit stronger than this and say that the intiial 
> shim6 work should have a goal of being compatible with existing mobility 
> solutions, such as MIP6 and NEMO.  I think that we should take a similar 
> goal regarding transport protocols, such as TCP, UDP and SCTP.

Agreed.

> It might (or might not) be the subject of later work to optimize the 
> interactions between shim6 and MIP6 and/or to develop new mobility 
> solutions based on shim6.

It might make sense to do some exploratory work on this in the form of a 
separate BoF, for instance, to better understand how the pieces might 
fir together in the future.

    Erik

Delivery-date: Fri, 18 Mar 2005 20:08:05 +0000
Date: Fri, 18 Mar 2005 12:07:29 -0800
From: Erik Nordmark <[email-masked]>
To: Thierry Ernst <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Thierry Ernst wrote:

> I have to take the opportunity of this mail to mention that a few people
> and I are involved into setting up a BOF in Paris. I would be called
> "Monami6" i.e. MObile NOdes and Multiple Interfaces in IPv6".  We still
> have to come up with clear problem statement drafts and a charter
> description, we are working on it and we should come up with something
> clear enough in the course of mid-april / end of april. The ML is
> already set up on the IETF mailman server but I will make a proper
> annoucement when drafts are updated on the IETF reposirtory are we would
> prefer to have comments on the updated versions.
> 
> This BOF would be clearly about bringing additional mechanisms to mobile
> host or routers operating Mobile IPv6 or NEMO BS. 

I sure hope the Monami6 BoF scope can be wider so that we can discuss 
the full set of interaction between multihoming and IP mobility, and not 
just discuss the multiple-CoA thing.

Registering multiple CoAs might be an important piece in the puzzle, but 
without looking at the whole problem it is impossible to tell how 
critical that (or any other) piece is.

    Erik

Delivery-date: Fri, 18 Mar 2005 19:35:42 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Fri, 18 Mar 2005 14:35:36 -0500
From: "Bound, Jim" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Kurtis Lindqvist" <[email-masked]>, "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>, "Leif Johansson" <[email-masked]>, <[email-masked]>

> Bound, Jim wrote:
> > Erik, thanks.  If we are to do this really I agree with 
> your mail below
> > technically.  The key is that the ULID is dereferenced to an address
> > whereever possible in the nodes stack and always on the 
> wire and if ULID
> > must be passed over the wire it must be in some encaped dst 
> option is one
> > suggestion.  Also how do I trust it on the wire?

> Are you concerned about the end-to-end behavior, or 
> routers/middleboxes 
> looking at the ULIDs and locators?

Yes and what must be on the wire are valid IP addresses in the header.
As we don't know what these will look like and how they are to be
managed it is uclear and not your shim spec
draft-ietf-multi6-l3shim-00.txt.  Add network management to that etc.
The point is that multihoming architecture should solve that specific
set of problems not cause any change to the rest of the network
operational infrastructure.  That is why I still believe SCTP is the
correct approach by adding ULID extensions, we are reinventing the
wheel.  The engineering cost and time to market for implementation will
be faster if we use SCTP and build TCP shims for multihoming. And we can
meet a reasonable time to market product set introduction.  The ULID for
the wire should be carried as a DST Option. I will wait for your next
spec to comment on how this can be done and slight changes to some of
the diagrams in the spec.  But figure your putting out a new spec soon
on that now, if not I can send you offline comments.  This effort should
not impact the rest of the Internet network implementations or it will
never happen. 

> The end-to-end behavior is trusted 
> using the HBA/CGA way to secure the relationship between the 
> addresses.

This was not my concern but I don't buy this entire belief of CGA and
either do many security viewpoints in industry. CGA is way over sold and
hyped.

> 
> If routers/middleboxes look at the packets (e.g. for QoS), 
> then in might 
> be best to have them use the locators (i.e., what's in the source and 
> destination address fields in the IPv6 header) since they are 
> as trusted 
> as today (which isn't very much). This means that signaling protocols 
> that today pass addresses to routers/middleboxes, need to 
> pass the set 
> of addresses instead of a single address.

Yes you discuss this in the draft above and left it that this may have
other problems.  I agree. But to my point above the multihoming solution
should not have to cause "signaling protocols" to change.  That is my
concern and most of my concerns are take care of if the src and dst
addresses are IPv6 addresses and only them in the header when entering
the wire.

Also what about MIBs, Intrusion Detection, etc all that assume IPv6
addresses which appear to be unaffected at least at IP layer 3-5.

/jim
> 
>      Erik
> 

Delivery-date: Fri, 18 Mar 2005 19:25:36 +0000
Date: Fri, 18 Mar 2005 21:25:53 +0200
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: how mobile do we want to be

Iljitsch van Beijnum wrote:

> No, but it does need a home address, so you don't get multihoming with 
> existing mobility. If you want multihoming AND mobility you need 
> strong crypto to authenticate adding addresses to existing sessions. 
> You are right that CGAs could at least avoid the need for a PKI, but 
> they're still relatively heavy-weight.

You need strong security in either static or dynamic multihoming case; I 
think
we agree that HBAs are strong. My point was that there is no infrastructure
involved either way. What you are saying does not relate to the need for
infrastructure but rather the computational effort. Well, things change
over time. My cell phone has had TLS and PK crypto operations for ages,
and some phones do VPNs with Diffie-Hellman. My take is that this type
of computation is cheap enough now.

> For those of you who weren't there: there has been discussion in 
> multi6 and its various design teams about whether a single solution 
> would be usable for all multihoming needs. Such a solution would then 
> have to cater to the highest performance, most restricted devices, 
> least secure environments and highest security requirements at the 
> same time. Dropping one or two of these extremes makes everything 
> _much_ easier.

I tend to think that it doesn't have a very big impact. And I'm not saying
this just because I have an opinion... we've actually done the design.

Actually, I don't think we should be debating the mobility issue so
heavily, because my belief is that the technical solution is going to be
the same no matter what we decide. Also, there'd be other, more
significant fights to fight if we want to look at issues like that. For
instance, can you multihome when you are GPRS connected on one
IPv6 interface and simultaneously doing NATted IPv4 WLAN on
another? This is in fact a pretty likely scenario -- and known to be
solvable. Anyway, the group has since long time decided to focus
on IPv6, for better or worse.

> What about the patent situation?

Well, I have no news about that. Are you saying that there'd be
a difference wrt HBA and CGA? Anyway, patents were not an
issue in SEND, because free licenses were granted. Not to
mention some other IETF technologies where even RAND
has been acceptable.

--Jari

Delivery-date: Fri, 18 Mar 2005 19:16:54 +0000
Cc: <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Thierry Ernst" <[email-masked]>
From: Ryuji Wakikawa <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Sat, 19 Mar 2005 04:15:27 +0900
To: "Bound, Jim" <[email-masked]>

Hi

My comment was for Margaret's observation.

> It might (or might not) be the subject of later work to optimize the 
> interactions between shim6 and MIP6 and/or to develop new mobility 
> solutions based on shim6.

I'm also interested in technical discussion, but
I believe this clarification was important to some other WG.

I did not see any technical discussion on this ML since my subscription,
because of this thread? Why?
ML is always open for any discussion, right?

regards,
ryuji

On 2005/03/19, at 4:03, Bound, Jim wrote:

> Hello,
>
>> Since SHIM6 and MIP6/NEMO are very similar design concept (to me),
>> it indicates that MIP6/NEMO are also capability to support
>> site/end-multihoming by itself.
>
> Would you tell us why you believe SHIM6 and MIP6/NEMO in technical
> architecture terms?  Thanks.
>
> P.S. Chairs I believe there is consensus we are to focus on multihoming
> and not mobility.  If I am correct my input is for you to shut down 
> this
> discussion and many mails that are doing nothing to further the 
> delivery
> of a multihoming solution.  But I will continue as above to discuss
> interesting points raised that are clear technically and worth my 
> tiime.
> thanks
>
> /jim

Delivery-date: Fri, 18 Mar 2005 19:03:55 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Fri, 18 Mar 2005 14:03:52 -0500
From: "Bound, Jim" <[email-masked]>
To: "Ryuji Wakikawa" <[email-masked]>, "Margaret Wasserman" <[email-masked]>
Cc: "Thierry Ernst" <[email-masked]>, <[email-masked]>

Hello,

> Since SHIM6 and MIP6/NEMO are very similar design concept (to me),
> it indicates that MIP6/NEMO are also capability to support 
> site/end-multihoming by itself. 

Would you tell us why you believe SHIM6 and MIP6/NEMO in technical
architecture terms?  Thanks.

P.S. Chairs I believe there is consensus we are to focus on multihoming
and not mobility.  If I am correct my input is for you to shut down this
discussion and many mails that are doing nothing to further the delivery
of a multihoming solution.  But I will continue as above to discuss
interesting points raised that are clear technically and worth my tiime.
thanks

/jim

Delivery-date: Fri, 18 Mar 2005 19:03:12 +0000
Date: Fri, 18 Mar 2005 11:02:15 -0800
From: Erik Nordmark <[email-masked]>
To: "Bound, Jim" <[email-masked]>
CC: Kurtis Lindqvist <[email-masked]>, Pasi Sarolahti <[email-masked]>, ext Iljitsch van Beijnum <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
Subject: Re: shim - transport/app communication

Bound, Jim wrote:
> Erik, thanks.  If we are to do this really I agree with your mail below
> technically.  The key is that the ULID is dereferenced to an address
> whereever possible in the nodes stack and always on the wire and if ULID
> must be passed over the wire it must be in some encaped dst option is one
> suggestion.  Also how do I trust it on the wire?

Are you concerned about the end-to-end behavior, or routers/middleboxes 
looking at the ULIDs and locators? The end-to-end behavior is trusted 
using the HBA/CGA way to secure the relationship between the addresses.

If routers/middleboxes look at the packets (e.g. for QoS), then in might 
be best to have them use the locators (i.e., what's in the source and 
destination address fields in the IPv6 header) since they are as trusted 
as today (which isn't very much). This means that signaling protocols 
that today pass addresses to routers/middleboxes, need to pass the set 
of addresses instead of a single address.

     Erik

Delivery-date: Fri, 18 Mar 2005 18:44:08 +0000
Cc: Thierry Ernst <[email-masked]>, [email-masked]
From: Ryuji Wakikawa <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Sat, 19 Mar 2005 03:43:44 +0900
To: Margaret Wasserman <[email-masked]>

Hello Margaret

I just subscribed to list and may miss some background of this 
discussion.
some comments.

On 2005/03/19, at 1:56, Margaret Wasserman wrote:

>
> Hi Thierry,
>
>> Another one is saying that "initially the WG will focus only on site
>> multihoming" but "will later investigate the impact on exisiting
>> protocols, particularly mobility related ones such as MIPv6, NEMO,
>> FMIPv6, HMIPv6".
>
> I would actually be bit stronger than this and say that the intiial 
> shim6 work should have a goal of being compatible with existing 
> mobility solutions, such as MIP6 and NEMO.  I think that we should 
> take a similar goal regarding transport protocols, such as TCP, UDP 
> and SCTP.
> It might (or might not) be the subject of later work to optimize the 
> interactions between shim6 and MIP6 and/or to develop new mobility 
> solutions based on shim6.

Interactions between shim6 and MIP6 are necessary, when SHIM6 becomes 
RFC.
BUT, SHIM6 should not be solo solution to achieve end/site multihoming.

Indeed, it's also important to look at possible multihoming solutions 
for
MIP6 or NEMO protocol in "other" WG, maybe MIP6, Monami, NEMO.

Since SHIM6 and MIP6/NEMO are very similar design concept (to me),
it indicates that MIP6/NEMO are also capability to support 
site/end-multihoming by itself.

MIP6 already has a unique address (HoA),
It's not big changes to MIP6 to bind multiple CoAs to the HoA. It's 
same for MR, too.

regards,
ryuji

Delivery-date: Fri, 18 Mar 2005 17:40:43 +0000
Date: Fri, 18 Mar 2005 18:40:32 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dave Crocker <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Dave,

I can't speak for other people, but my desire to limit the
shim6 charter is because I don't believe we have any chance
of rapid success unless we tackle a finite and well understood
problem.

The general issues of mobility are currently arousing some
interest in the IAB, which seems the right place.

I don't, however, believe that shim6 does any harm to
mobility, and ensuring that property is in scope, of course.

     Brian

Dave Crocker wrote:
>  On Fri, 18 Mar 2005 13:24:46 +0100, Brian E Carpenter wrote:
> 
>>  We didn't exclude the discussion. I'm just stating it as my
>>  opinion that the draft charter is correct on this point, and that
>>  this was already clear in the multi6 discussions.
> 
> 
> the history of this line of consideration is that it has pretty much always excluded any serious effort to integrate mobility and multihoming. when the initial round of many presentations was done, in multi6, integration with mobility was automatically deferred to 'some other group'. 
> 
> in case no one has noticed, responses to efforts at pursuing such an integration discussion have pretty much always tended to be similar to the responses appearing on this thread.  those responses are automatic rejection, without any interest in seeing whether integration really can make sense. in other words, the tone of this online discussion has had more to do with religion than analysis.
> 
> my original posting, here, was attempting to compare this choice to a decision to have tcp behave very differently in lans than in wans -- in other words, to have two different tcps.  the response, here, has been the equivalent of "lans are different from wans, so it's fine to have a different solution for tcp."
> 
> it is certainly true that some definitions of mobility and some definitions of multihoming can permit no useful overlap in the technical solution. 
> 
> however it is also true that that some definitions permit a very high degree of overlap.  folks seem curiously uninterested in being clear about the reasons for choosing the former, rather than the latter, given the serious long-term costs of having different solutions.
> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
> 

Delivery-date: Fri, 18 Mar 2005 17:10:25 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 18:10:13 +0100
To: Jari Arkko <[email-masked]>

On 18-mrt-05, at 17:58, Jari Arkko wrote:

> Actually, I think we can eat the cake and save it too.
> In fact, if you look at the basic mechanisms already
> proposed for Multi6/Shim6, at their fundamental
> level they *are* capable of doing both multihoming
> and mobility, and with either fast or slowly changing
> addresses. I'm talking about the use of the existing
> CGA format for HBAs, which allows the use of dynamic
> addresses when necessary.

What about the patent situation?

> P.S. There is no proposal on the table that
> would use PKI for anything. Mobility as such
> doesn't need PKI.

No, but it does need a home address, so you don't get multihoming with 
existing mobility. If you want multihoming AND mobility you need strong 
crypto to authenticate adding addresses to existing sessions. You are 
right that CGAs could at least avoid the need for a PKI, but they're 
still relatively heavy-weight.

For those of you who weren't there: there has been discussion in multi6 
and its various design teams about whether a single solution would be 
usable for all multihoming needs. Such a solution would then have to 
cater to the highest performance, most restricted devices, least secure 
environments and highest security requirements at the same time. 
Dropping one or two of these extremes makes everything _much_ easier.

Delivery-date: Fri, 18 Mar 2005 16:58:33 +0000
Date: Fri, 18 Mar 2005 18:58:49 +0200
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: Dave Crocker <[email-masked]>, shim6 <[email-masked]>
Subject: Re: how mobile do we want to be

Iljitsch,

Actually, I think we can eat the cake and save it too.
In fact, if you look at the basic mechanisms already
proposed for Multi6/Shim6, at their fundamental
level they *are* capable of doing both multihoming
and mobility, and with either fast or slowly changing
addresses. I'm talking about the use of the existing
CGA format for HBAs, which allows the use of dynamic
addresses when necessary.

Of course we can question how much emphasis the
WG shall put on that.

--Jari

P.S. There is no proposal on the table that
would use PKI for anything. Mobility as such
doesn't need PKI.

Iljitsch van Beijnum wrote:

> On 18-mrt-05, at 16:59, Dave Crocker wrote:
>
>> however it is also true that that some definitions permit a very high 
>> degree of overlap.  folks seem curiously uninterested in being clear 
>> about the reasons for choosing the former, rather than the latter, 
>> given the serious long-term costs of having different solutions.
>
>
> Multihomed, mobile, simple: pick any two.
>
> (Where simple is of course relative and mainly means "no PKI necessary".)
>
>
>
>

Delivery-date: Fri, 18 Mar 2005 16:57:06 +0000
Date: Fri, 18 Mar 2005 11:56:48 -0500
To: Thierry Ernst <[email-masked]>, [email-masked]
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be

Hi Thierry,

>Another one is saying that "initially the WG will focus only on site
>multihoming" but "will later investigate the impact on exisiting
>protocols, particularly mobility related ones such as MIPv6, NEMO,
>FMIPv6, HMIPv6".

I would actually be bit stronger than this and say that the intiial 
shim6 work should have a goal of being compatible with existing 
mobility solutions, such as MIP6 and NEMO.  I think that we should 
take a similar goal regarding transport protocols, such as TCP, UDP 
and SCTP.

It might (or might not) be the subject of later work to optimize the 
interactions between shim6 and MIP6 and/or to develop new mobility 
solutions based on shim6.

Margaret

Delivery-date: Fri, 18 Mar 2005 16:40:35 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 17:40:23 +0100
To: Dave Crocker <[email-masked]>

On 18-mrt-05, at 16:59, Dave Crocker wrote:

> however it is also true that that some definitions permit a very high 
> degree of overlap.  folks seem curiously uninterested in being clear 
> about the reasons for choosing the former, rather than the latter, 
> given the serious long-term costs of having different solutions.

Multihomed, mobile, simple: pick any two.

(Where simple is of course relative and mainly means "no PKI 
necessary".)

Delivery-date: Fri, 18 Mar 2005 16:00:16 +0000
From: Dave Crocker <[email-masked]>
To: Brian E Carpenter <[email-masked]>, Thierry Ernst <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Fri, 18 Mar 2005 07:59:49 -0800
Subject: Re: how mobile do we want to be

 On Fri, 18 Mar 2005 13:24:46 +0100, Brian E Carpenter wrote:
>  We didn't exclude the discussion. I'm just stating it as my
>  opinion that the draft charter is correct on this point, and that
>  this was already clear in the multi6 discussions.

the history of this line of consideration is that it has pretty much always excluded any serious effort to integrate mobility and multihoming. when the initial round of many presentations was done, in multi6, integration with mobility was automatically deferred to 'some other group'. 

in case no one has noticed, responses to efforts at pursuing such an integration discussion have pretty much always tended to be similar to the responses appearing on this thread.  those responses are automatic rejection, without any interest in seeing whether integration really can make sense. in other words, the tone of this online discussion has had more to do with religion than analysis.

my original posting, here, was attempting to compare this choice to a decision to have tcp behave very differently in lans than in wans -- in other words, to have two different tcps.  the response, here, has been the equivalent of "lans are different from wans, so it's fine to have a different solution for tcp."

it is certainly true that some definitions of mobility and some definitions of multihoming can permit no useful overlap in the technical solution. 

however it is also true that that some definitions permit a very high degree of overlap.  folks seem curiously uninterested in being clear about the reasons for choosing the former, rather than the latter, given the serious long-term costs of having different solutions.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Fri, 18 Mar 2005 12:25:11 +0000
Date: Fri, 18 Mar 2005 13:24:46 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Thierry Ernst <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Thierry Ernst wrote:
> 
> On Fri, 18 Mar 2005 11:12:02 +0100
> Brian E Carpenter <[email-masked]> wrote:
> 
>>>So please let's do this shim in peace and revisit the interaction
>>>with  other stuff when there is something concrete to build on.
>>>
>>>
>>
>>Yes, that was the clear consensus of the multi6 discussion
>>and that's why the shim6 draft charter is the way it is. I see
>>no value in restarting that debate.
> 
> 
> Would you explain me what is the purpose of a BOF if you exclude
> discussions ? Just don't do BOF and straight approve the WG then. 

We didn't exclude the discussion. I'm just stating it as my
opinion that the draft charter is correct on this point, and that
this was already clear in the multi6 discussions.

> 
> Should be easy now given your recent functions, but it won't do any good
> to the reputation of the IETF;-)

I specifically indicated that I was writing as ex-WG chair and ex-BOF
chair.

     Brian

Delivery-date: Fri, 18 Mar 2005 10:56:16 +0000
Date: Fri, 18 Mar 2005 20:00:31 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

On Fri, 18 Mar 2005 11:12:02 +0100
Brian E Carpenter <[email-masked]> wrote:
> > So please let's do this shim in peace and revisit the interaction
> > with  other stuff when there is something concrete to build on.
> > 
> > 
> Yes, that was the clear consensus of the multi6 discussion
> and that's why the shim6 draft charter is the way it is. I see
> no value in restarting that debate.

Would you explain me what is the purpose of a BOF if you exclude
discussions ? Just don't do BOF and straight approve the WG then. 

Should be easy now given your recent functions, but it won't do any good
to the reputation of the IETF;-)

> It's very important that the charter excludes this discussion, so
> that when the WG starts it can write the shim6 specifications
> without distraction.

There are different ways to excude a discussion from a debate. 

One is to say "discussion related to mobility" is excluded from this
charter, but this looks a bit like stalinism. I didn't know (well, I
should say "believe" ) the IETF works this way.

Another one is saying that "initially the WG will focus only on site
multihoming" but "will later investigate the impact on exisiting
protocols, particularly mobility related ones such as MIPv6, NEMO,
FMIPv6, HMIPv6". Such phrasins works (at least it works in the NEMO WG
where we were succesful to concentrate on a basic solution while leaving
the appealing route optimization for once the NEMO Basic Support spec is
released. I think it can work for Shim6 too).

I give more credits to the mail sent by  Kurtis:
On Fri, 18 Mar 2005 12:21:16 +0200 (EET)
Kurtis Lindqvist <[email-masked]> wrote 
> 	Thierry,
> 
> On Thu, 17 Mar 2005, Thierry Ernst wrote:
> > opportunity window and that we may be losing a good opportunity to
> > solve once for all the mobility problem if we don't investigate it
> > further.
> 
> During the BOF I made the point that there is little or nothing
> special with mobility in the context of shim6. And I personally think
> that what input is needed should come from mobile working groups. But
> we need to work on some form of update to the charter also with the
> ADs.

Yes,  I think that the intention behind my many mails is some kind of
update to the draft charter to reflect the past discussions and
concerns. But please allow me to comment again if I don't see the
concerns reasonably well addressed.

Thierry

Delivery-date: Fri, 18 Mar 2005 10:21:20 +0000
Date: Fri, 18 Mar 2005 12:21:16 +0200 (EET)
From: Kurtis Lindqvist <[email-masked]>
To: Thierry Ernst <[email-masked]>
Cc: [email-masked]
Subject: Re: how mobile do we want to be

	Thierry,

On Thu, 17 Mar 2005, Thierry Ernst wrote:
> opportunity window and that we may be losing a good opportunity to solve
> once for all the mobility problem if we don't investigate it further.

During the BOF I made the point that there is little or nothing special
with mobility in the context of shim6. And I personally think that what
input is needed should come from mobile working groups. But we need to
work on some form of update to the charter also with the ADs.

> However, I'm not sure it should be the purpose of the Shim6 WG as my
> understanding is that it would produce Experimental RFCs, so I would
> find myself satisfied in this situation, provied mobility is
> investigated at the IETF.
>

I don't think shim6 is targeting Experimental RFCs, but rather Standard.

- kurtis -

Delivery-date: Fri, 18 Mar 2005 10:12:21 +0000
Date: Fri, 18 Mar 2005 11:12:02 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Thierry Ernst <[email-masked]>, [email-masked]
Subject: Re: how mobile do we want to be

Iljitsch van Beijnum wrote:
> On 18-mrt-05, at 4:04, Thierry Ernst wrote:
> 
>> I second the fact that the deployment of any important architectural
>> change should mandate a solution to both multihoming, mobility,
>> security, multicast and so on.  [here, I'm speaking about deployment,
>> not the charter].
> 
> 
> I'm sorry, but forcing a multihoming solution to address mobility and 
> multicast as well is insane. There is no evidence that layer 3 mobility 
> is even useful or necessary, and the repeated claim that so many devices 
> will be mobile without addressing the question whether these devices 
> will actually want or need layer 4 sessions to move from one address to 
> another only supports my suspicion that mobility is an answer in search 
> of a question. Interdomain multicast doesn't exist if we round down to a 
> reasonable number of digits.
> 
> And regardless of the merits of these technologies, _I_ am not willing 
> to work on multihoming if mobility and multicast must be supported in 
> the first version of the protocol, because I can't spare the additional 
> time and I'm unwilling to accept the additional risk of failure. I 
> suspect the same is true for most others who've been active in multi6.
> 
> So please let's do this shim in peace and revisit the interaction with 
> other stuff when there is something concrete to build on.
> 
> 
Yes, that was the clear consensus of the multi6 discussion
and that's why the shim6 draft charter is the way it is. I see
no value in restarting that debate.

It's very important that the charter excludes this discussion, so
that when the WG starts it can write the shim6 specifications
without distraction.

Brian (writing as ex-multi6 chair and ex-shim6 BOF chair)

Delivery-date: Fri, 18 Mar 2005 08:59:29 +0000
Date: Fri, 18 Mar 2005 18:03:49 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

> > I second the fact that the deployment of any important architectural
> > change should mandate a solution to both multihoming, mobility,
> > security, multicast and so on.  [here, I'm speaking about
> > deployment, not the charter].
> 
> I'm sorry, but forcing a multihoming solution to address mobility and 
> multicast as well is insane. 

Did I wrote I was not speaking about the charter but deployment ?

> There is no evidence that layer 3
> mobility  is even useful or necessary, and the repeated claim that so
> many  devices will be mobile without addressing the question whether
> these  devices will actually want or need layer 4 sessions to move
> from one  address to another only supports my suspicion that mobility
> is an  answer in search of a question. Interdomain multicast doesn't
> exist if  we round down to a reasonable number of digits.

This is a short-sighted point of view. There is no question to me that
most of the sessions will have to sustain layer 3 handoffs (I mean, if
we deploy the right IP technology, the applications and usages will want
it). But since this is a point of view on things which don't exist yet,
I'm afraid that the discussion is a rat-hole.

> And regardless of the merits of these technologies, _I_ am not willing
>  to work on multihoming if mobility and multicast must be supported in
> the first version of the protocol, because I can't spare the
> additional  time and I'm unwilling to accept the additional risk of
> failure. I  suspect the same is true for most others who've been
> active in multi6.

So, in this case you shouldn't have any concern, see at the end of this
mail (you would a peace to focus on this **initially**).

> So please let's do this shim in peace and revisit the interaction with
>  other stuff when there is something concrete to build on.

If you want peace I'm afraid the IETF is not the right place to do it
;-) 

If your point of view is that people like me who are sceptical about
the words in the current charter shouldn't express their concerns, then
go ahead, and there is no needs for BOF, charter, and so on at the IETF
anymore. 

Note - I'm repeating myself - than I don't say I oppose a WG, but:

- I think experimental RFC would make better sense than draft standards 
(this would give room to work on a focused topic without risk such an
architectural change is deployed without considering mobility; at
the same time this would allow time for other researching on the
mobility aspects so that draft standards are produced when the question
has been fully pondered. 

  => I would like to make sure this point is discussed when the WG is to
be approved/disapproved.

- a twin IRTF work would be nice to look into the wider aspects such as
mobility

- a word saying that the WG will focus on the sole site
multihoming aspect initially, but that it will consider mobility
later 

- a word saying that the shim6 solution must make sure other standards
such as MIP6, NEMO can work unchanged (no hurt - this was seconded by
other people on this thread and at the BOF): this implies an analysis
document.

Thierry

Delivery-date: Fri, 18 Mar 2005 08:28:32 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Fri, 18 Mar 2005 10:25:01 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Ilitsch,

> So please let's do this shim in peace and revisit the interaction with 
> other stuff when there is something concrete to build on.

I agree completely!

John

Delivery-date: Fri, 18 Mar 2005 07:58:34 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Fri, 18 Mar 2005 08:58:19 +0100
To: Thierry Ernst <[email-masked]>

On 18-mrt-05, at 4:04, Thierry Ernst wrote:

> I second the fact that the deployment of any important architectural
> change should mandate a solution to both multihoming, mobility,
> security, multicast and so on.  [here, I'm speaking about deployment,
> not the charter].

I'm sorry, but forcing a multihoming solution to address mobility and 
multicast as well is insane. There is no evidence that layer 3 mobility 
is even useful or necessary, and the repeated claim that so many 
devices will be mobile without addressing the question whether these 
devices will actually want or need layer 4 sessions to move from one 
address to another only supports my suspicion that mobility is an 
answer in search of a question. Interdomain multicast doesn't exist if 
we round down to a reasonable number of digits.

And regardless of the merits of these technologies, _I_ am not willing 
to work on multihoming if mobility and multicast must be supported in 
the first version of the protocol, because I can't spare the additional 
time and I'm unwilling to accept the additional risk of failure. I 
suspect the same is true for most others who've been active in multi6.

So please let's do this shim in peace and revisit the interaction with 
other stuff when there is something concrete to build on.

Delivery-date: Fri, 18 Mar 2005 03:15:33 +0000
Date: Fri, 18 Mar 2005 12:19:57 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

Hi,

OK, John was a big vague about what he was thinking about when
mentioning a BOF. May be a link to some drafts would help to clarify if
it's advanced work or more longer term.

I have to take the opportunity of this mail to mention that a few people
and I are involved into setting up a BOF in Paris. I would be called
"Monami6" i.e. MObile NOdes and Multiple Interfaces in IPv6".  We still
have to come up with clear problem statement drafts and a charter
description, we are working on it and we should come up with something
clear enough in the course of mid-april / end of april. The ML is
already set up on the IETF mailman server but I will make a proper
annoucement when drafts are updated on the IETF reposirtory are we would
prefer to have comments on the updated versions.

This BOF would be clearly about bringing additional mechanisms to mobile
host or routers operating Mobile IPv6 or NEMO BS. 

I think what Erik and John are talking about is something wider than
this in scope, and not focused on existing RFC 3963 and RFC 3775. So, to
clarify what I meant, extensions to Mobile IPv6 have been proposed for
years and years with little support from the Mobile IP WGs. However,
such extensions (e.g. draft-wakikawa-mobileip-multiplecoa-04.txt
[currently just expired, but a replacement draft will be posted in a
couple of days]) are mature enough.

Thierry

Erik Nordmark <[email-masked]> wrote:

> Thierry Ernst wrote:
> 
> > I disagree a BOF is needed, what is needed is to tackled with this
> > specific problem at the **IRTF**. There are more mature topics on
> > which IETF WGs have been (wrongly) disapproved while this is pretty
> > straight forward to me that it should be IRTF in the present case.
> 
> Thierry,
> you must have a very different view of what the problem is than I
> have,  because I had engineering solutions to how multihoming and
> mobile IP can  be combined in useful ways that I could discuss in a
> BoF, and I don't  see the research questions.
> 
> So perhaps you can say what you see as the hard research issues in
> this  space.
> 
> FWIW I look at the rather simple case of hosts and stub networks that 
> move while being connected to the Internet at multiple points, and not
>  the more MANET-like case where everything moves at the same time. I
>  see 
> the latter as MANET issues.
> 
>     Erik

Delivery-date: Fri, 18 Mar 2005 03:00:16 +0000
Date: Fri, 18 Mar 2005 12:04:38 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

I thought it was "experimental", sorry for the confusion. I either
missundertood, or someone mentioned about "experimental" and I caught
that word more loudly that it really is. 

So, if it's not experimental, I even more agree with Avri that engaging
ourselves in such an architectural change may be a wrong direction or
imature or a loss of opportunity.

I second the fact that the deployment of any important architectural
change should mandate a solution to both multihoming, mobility,
security, multicast and so on.  [here, I'm speaking about deployment,
not the charter].

Thierry

On Fri, 18 Mar 2005 10:02:30 +1100
Geoff Huston <[email-masked]> wrote:

> At 09:56 AM 18/03/2005, Margaret Wasserman wrote:
> >At 9:48 AM +1100 3/18/05, Geoff Huston wrote:
> >>I'd have to agree with Marcelo here. Its certainly my impression
> >that our  >specific mission in the context of this WG is to develop
> >the shim6 drafts  >into standards track specifications.
> >
> >We haven't officially chartered the WG yet (I'm waiting for updated 
> >charter text that reflects the BOF description, so that I can put it
> >on  the IESG agenda).
> 
> 
> true - I was careful to refer to a "mission" rather than a "charter"
> for  that reason - :-)
> 
> 
> >However, it is certainly my expectation that this group will product 
> >standards track specifications.  It says so explicitly in the charter
> >text  that we've been discussing for the past few months.
> 
> Geoff
> 

Delivery-date: Fri, 18 Mar 2005 02:54:33 +0000
Date: Fri, 18 Mar 2005 11:58:03 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

Margaret Wasserman <[email-masked]> wrote:
> Hi Thierry,
> 
> At 12:35 PM +0900 3/17/05, Thierry Ernst wrote:
> >There are diffrent topics when we do think about the motivations /
> >needs, but that may be similar when thinking about mobility. Mobility
> >solutions could serve as a means to renumber/multihome and
> >multihoming solutions could serve as a means to solve mobility ...
> >So, it's not orthogonal as it depends from which perspective you look
> >at the picture.
> 
> I did not say that the definitions of mobility, renumbering and 
> multihoming are orthogonal (i.e. completely independent).  I said 
> that they are tangential (somewhat related).

Oops, you did, actually. I think I was confused with other mails, I
think someone mentioned "orthogonal". So, yes, then I agree with the
term tangential.

> >"IP-layer mobility" means changing the L3 point of attachment and
> >"mobility support" is the abilitiy to do this without losing the
> >sessions. Such mobility necessarily means that the topological
> >location of the node would be changed (if not, I don't understand the
> >scenario), and, in such a case, that the IP address would be changed
> >(an interface must obtain an address on the link it is attached to,
> >right ?). However, depending on the solution to support this, upper
> >layers may not see the change of IP address (e.g. mobility).
> 
> I am not sure that the world-at-large has accepted your definition of 
> the term "mobility" to apply only to those cases when a node moves 
> from one IP subnet to another.  In a large bridged/VLAN network, a 
> host can move about freely (even between buildings) without changing 
> it's location in the L3 topology, through the use of dynamic VLANs or 
> other L2 mobility solutions.  The node's IP address doesn't change, 
> and no L3 mobility solution is needed to reach it.  In fact, the L3 
> protocols are unaware that the node has moved.

Agree, this is L2 mobility, right ? not IP layer mobility.

The scenario you depicted is exactly the one that applies to our campus
(L2 bridging)  (though we can also do a L3 handoff as each lab has it's
own WLAN in addition to the campus WLAN).

> Another case where mobility is handled at L2 (at least from the 
> perspective of the top-level IP layer) is 3GPP.  The mobility of the 
> node is handled by the 3GPP network, not by an IP-layer mobility 
> solution.

Perfectly agree. I think your initial definition was not clear as you
just mentioned "mobility" whereas you should have said either "IP-layer
mobility" or "link-layer mobility"

> >>  There are two subtypes of mobility:  mobility within a campus
> >(under >  a single administrative domain) and mobility across the
> >Internet.
> >
> >This is called Macro/Global mobility and Micro/Local mobility (see
> >RFC 3753).
> 
> Okay.
> 
> >>  Mobility within a campus is most often handled by layer 2
> >protocols, >  such as dynamic VLANs, that require no change to the
> >node's >  topological location (IP prefixes or addresses).  Mobility
> >across the >  Internet does require some change to the topological
> >information, at >  least at some level, and is handled by MIP (v4 or
> >v6).
> >
> >You can move into a campus and do a L3 handoff between 2 subnets
> >(i.e. L3). If the service provider is different, this is "global
> >mobility", if it's the same provider (2 WLAN, with no L2-bridging)
> >this is "local mobility".
> 
> You can also move within a campus/administrative domain with no L3 
> handoff at all, assuming that there are L2 mechanisms to support this.

I think we didn't contradict eachother. It's just the term we use. I
think the simply saying "mobility" is not clear enough, nor saying
"campus mobility" as different people may have a different
interpretation of what that is. 

(I guess the chair may want to shut this discussion as we diverge from
mobility, but we don't threw darts away yet, so it may not be needed
;-)

> >>  Multihoming:  Allowing a node that has more than one topological
> >>  location within     the Internet to use its redundant paths for
> >>  efficient or reliable Internet connectivity. Note that multihoming
> >>  _does not_ involve changing the node's point(s) of attachment to
> >the >  Internet and/or changing the node's topological locations
> >within the >  Internet; the node has more than one topological
> >location on an >  ongoing basis.
> >
> >I agree that it's not straight forward to see shim6 applying for
> >mobility, but I think that what Avri was trying to say is that it
> >would be a shame if such an important change wouldn't at the same
> >time bring an answer to the mobility issue (particularly given the
> >fact that an important proportion of nodes would be mobile).
> 
> I believe that I understand Avri's position.  I just don't happen to 
> agree with it.
> 
> Part of my disagreement lies in the assumption that an important 
> proportion of the nodes will be mobile, where "mobile" is defined as 
> changing their location in the L3 topology while retaining active L4 
> sessions.  While I agree that an important number of nodes will move 
> about (laptops, cell phones, etc.), I do not expect that a 
> particularly large portion of the nodes will be mobile at L3 
> (changing their location in the L3 topology) while expecting (or even 
> wanting) L4 sessions to remain active.

I highly oppose to that statement. To me, either we continue to use the
Internet the way we do know and yes, I can agree with you, or either we
think about the new services, usages, and in this case, I tremendous
proportion of the Internet will be mobile:

- 6 billions people owning IPv6 mobile phones
- 700 millions vehicles with IPv6 embedded network 
- billions and billions of IPv6 walkmans/digital camera/PDAs/etc
- trillions of in-house equipments that people will bring with them when
they go for vacation, shopping, etc

The edge will be mostly mobile because the rationale is that all
electronic devices may be either carried by the people sometimes, or
embedded in moving networks.

I think we would better develop protocols which would allow this.

> We already have solutions for those nodes or networks that do need 
> true mobility, as defined in the previous paragraph: MIP* & NEMO.
> 
> What we don't have is a scalable multi-homing solution.

Right, but with the assumption that most nodes will at the same time be
multihomed AND mobile. It the solutions for multihoming works for
mobility, very fine, we can take a break. 

But having a multihomed solution which doesn't allow mobility is
clearly bad engineering (at best).

On the other side, developping mobility solutions which doesn't allow
multihoming is also bad engineering, and this is why I do work on
enable all kind of multihoming scenarios using NEMO Basic Support and
Mobile IPv6.

> >So, playing an evil game, mobility-concerned people may wonder what
> >is the benefit of such an architectural changes if the mobility
> >problem remain unchanged ? (does it worth the effort ?).
> 
> The benefit is that it solves the scalable multihoming problem, and 
> some of us consider that an important problem to solve.

I agree it's an important problem to solve, but I do insist that if it
prevent multihomed sites to be mobile, then it's bad engineering.

Thierry

Delivery-date: Thu, 17 Mar 2005 23:05:46 +0000
Date: Fri, 18 Mar 2005 10:02:30 +1100
To: Margaret Wasserman <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Thierry Ernst <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: [email-masked]

At 09:56 AM 18/03/2005, Margaret Wasserman wrote:
>At 9:48 AM +1100 3/18/05, Geoff Huston wrote:
>>I'd have to agree with Marcelo here. Its certainly my impression that our 
>>specific mission in the context of this WG is to develop the shim6 drafts 
>>into standards track specifications.
>
>We haven't officially chartered the WG yet (I'm waiting for updated 
>charter text that reflects the BOF description, so that I can put it on 
>the IESG agenda).

true - I was careful to refer to a "mission" rather than a "charter" for 
that reason - :-)

>However, it is certainly my expectation that this group will product 
>standards track specifications.  It says so explicitly in the charter text 
>that we've been discussing for the past few months.

Geoff

Delivery-date: Thu, 17 Mar 2005 22:57:03 +0000
Date: Thu, 17 Mar 2005 17:56:38 -0500
To: Geoff Huston <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Thierry Ernst <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: [email-masked]

At 9:48 AM +1100 3/18/05, Geoff Huston wrote:
>I'd have to agree with Marcelo here. Its certainly my impression 
>that our specific mission in the context of this WG is to develop 
>the shim6 drafts into standards track specifications.

We haven't officially chartered the WG yet (I'm waiting for updated 
charter text that reflects the BOF description, so that I can put it 
on the IESG agenda).

However, it is certainly my expectation that this group will product 
standards track specifications.  It says so explicitly in the charter 
text that we've been discussing for the past few months.

Margaret

Delivery-date: Thu, 17 Mar 2005 22:50:55 +0000
Date: Fri, 18 Mar 2005 09:48:32 +1100
To: marcelo bagnulo braun <[email-masked]>, Thierry Ernst <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: [email-masked]

I'd have to agree with Marcelo here. Its certainly my impression that our 
specific mission in the context of this WG is to develop the shim6 drafts 
into standards track specifications.

regards,

    Geoff

At 02:07 AM 18/03/2005, marcelo bagnulo braun wrote:
>Hi Thierry,
>
>
>El 17/03/2005, a las 3:28, Thierry Ernst escribió:
>
>>
>>Dear all,
>>
>>I attended half the BOF, but couldn't stay until the end as I had to
>>take my flight, so, sorry if I raise issues which was discussed in the
>>BOF.
>>
>>First, I agree with what Avri said during the BOF - that there is an
>>opportunity window and that we may be losing a good opportunity to solve
>>once for all the mobility problem if we don't investigate it further.
>>
>>However, I'm not sure it should be the purpose of the Shim6 WG as my
>>understanding is that it would produce Experimental RFCs,
>
>Maybe i missed something here, but i don't recall that the goal of shim 
>was to produce exprimental RFCs, i guess we are here to produce standards 
>tracks.
>
>Chairs?
>
>Regards, marcelo
>
>
>
>>so I would
>>find myself satisfied in this situation, provied mobility is
>>investigated at the IETF.
>>
>>Iljitsch van Beijnum <[email-masked]> wrote:
>>>On 14-mrt-05, at 16:41, [email-masked] wrote:
>>>
>>>>I think the question is more a recognition that the network is now a
>>>>  network in motion:  systems move and networks move.  And while it
>>>>  is
>>>>true that some part so the network, doesn't move, or moves very
>>>>slowly, an overwhelming amount of the edge is in motion. And I think
>>>>  it is important to realize that a large number of  sessions should
>>>>remain viable despite this continuous motion.
>>
>>>Could you provide some examples of applications where a
>>>disconnect/reconnect is sufficiently problematic that MIPv6 or
>>>something similar is warranted?
>>>
>>>So far the only stuff I can think of is remote login and streaming
>>>audio/video.
>>
>>First, I've a question for Avri. What do you mean by "network in
>>motion", is this the mobile networks that we are supporting in the NEMO
>>WG, or something else ? (I would say yes, but since you didn't mention
>>NEMO, I cannot be sure).
>>
>>If NEMO scenarios are in mind, I would second Avri in saying that a
>>significant part of the Internet nodes would be "mobile" (either that
>>change their point of attachment [i.e. mobile host or mobile routers] or
>>they are located in a network which "gateway" is mobile).
>>
>>Basically, MIP6 bring a solution to the former, and NEMO BS to the
>>latter (thought NEMO BS is not providing routing optimization). That's
>>not the point. The point is that if Shinm6 is looking into a solution
>>which would require a major architectural change, then, yes, it would
>>make sense that this major architectural change takes mobility
>>explicitly into consideration. Here, I do agree with Avri.
>>
>>A conclusion might be that Shim6 is a little bit immature to be set up
>>at the IETF, whereas a IRFT WG on that (taking mobility into
>>consideration) might make more sense.
>>
>>>>In other words I think the question is not, "how mobile do we want
>>>>to  be", but how mobile are we and how mobile will we be by the time
>>>>a  shim6 solution is implemented and widely deployed.
>>>
>>>My prediction: not very. 99% of all traffic today is either sessions
>>>that go away within seconds, or can be easily reestablished after a
>>>forced disconnect. I don't see how the other 1% is going to take over
>>>the world any time soon.
>>
>>Hold on, if we only have 1% of mobile nodes today, it may be because the
>>Internet is not tuned for mobility, and that IPv6 is not yet deployed.
>>IPv6 is a change to deploy neew usages, and most of these new usages
>>will be mobile (see my comment about who is mobile ealier in my mail).
>>Every human will have a mobile phone, and possibly, many millions of
>>them will carry a PAN (ako NEMO). All cars will have an embedded network
>>(and that could be NEMO too). That's a few hundred millions cars.
>>
>>This will happen by the time the Shim6 solution is deployed (if it can
>>be deployed, which I'm not sure it would if mobility is not considered).
>>
>>
>>>>It is for these reasons that I am arguing so insistently that we
>>>>must  include systems and networks in motion (if we want to reserve
>>>>the term  mobility for MIP4/6 to avoid confusion) as part of the
>>>>problem space  shim6 must take into account.
>>>
>>>I don't think this is a good idea. Let's focus on the basic shim
>>>functionality, and when we have something useful there, we can sync up
>>>  with other efforts and see what we need to do to avoid duplication of
>>>
>>>effort and to gain synergy.
>>
>>Why this had to be done at the IETF ? (I'm just asking, not opposing,
>>and, in summary, my concern is that mobility should be investigated one
>>place or another if a Shim6 solution is ever expected to be deployed).
>>
>>Thierry.
>>
>
>
>

Delivery-date: Thu, 17 Mar 2005 17:46:59 +0000
Date: Thu, 17 Mar 2005 09:46:21 -0800
From: Erik Nordmark <[email-masked]>
To: Thierry Ernst <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Thierry Ernst wrote:

> I disagree a BOF is needed, what is needed is to tackled with this
> specific problem at the **IRTF**. There are more mature topics on which
> IETF WGs have been (wrongly) disapproved while this is pretty straight
> forward to me that it should be IRTF in the present case.

Thierry,
you must have a very different view of what the problem is than I have, 
because I had engineering solutions to how multihoming and mobile IP can 
be combined in useful ways that I could discuss in a BoF, and I don't 
see the research questions.

So perhaps you can say what you see as the hard research issues in this 
space.

FWIW I look at the rather simple case of hosts and stub networks that 
move while being connected to the Internet at multiple points, and not 
the more MANET-like case where everything moves at the same time. I see 
the latter as MANET issues.

    Erik

Delivery-date: Thu, 17 Mar 2005 15:31:42 +0000
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Thu, 17 Mar 2005 16:31:16 +0100
To: [email-masked]

Hi Jim,

El 17/03/2005, a las 5:55, Bound, Jim escribió:

> May I suggest a compromise view here.  Why don't we fix/focus on the
> multihoming problem.  In the course of that work we should do nothing 
> to
> hurt mobility as we must always think about security in the IETF work
> effort. If there is a mobility solution in our result it will be 
> evident
> to all.

fully agree with this approach

thanks, marcelo

> I see better where your going from the mail below.  I just
> believe we must remain focused on the multihoming problem.  I am 
> already
> extremely skeptical of shims first off as network experienced
> implementor and architect and one who ships products, if we try to 
> solve
> mobility too I will probably go away.  Not because its not
> interesting/important, but the engineer and leader part of my brain
> would be telling me this effort will not complete trying to solve both
> abstractions at the same time and consensus will not happen.  Thus not 
> a
> good use of my precious time, life, and my eyes that read so many IETF
> drafts etc.
>
> thanks
> /jim
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Thierry Ernst
>> Sent: Wednesday, March 16, 2005 11:46 PM
>> To: [email-masked]
>> Subject: Re: how mobile do we want to be
>>
>>
>>> I will take it further.  Margaret is correct and I will be stronger
>>> and replace the word tangential with orthogonal.  Mobility and
>>> Multihoming are completely two separate technology efforts and
>>> functions related to building a multihome archictecture, a network
>>> operations model for an enterprise, or a shim solution within an IP
>>> stack.
>>
>> The motiviations behind mobility and multihoming are distinct
>> (i.e. the
>> intention is orthogonal) but the solutions MAY be similar / could
>> apply to one another / could be the same (i.e. the result may not be
>> orthogonal).
>>
>>> Another example is Mobile IPv6 et al (multiple working groups
>>> on mobility) is completely orthogonal to MANETs problem of
>> routing or
>>> autoconfiguratin on the link.
>>>
>>>
>>> In my opinion I have seen some views expressed to try to integrate
>>> Mobility issues-problems-opportunities into the work of multihoming
>>
>> I'm not sure it's the intention. I would better take this as
>> a "concern"
>> (deploying an architectural change which doesn't solve the mobility
>> problem is at best a loss of opportunity and at worse a lack of
>> planning) . I personaly have no intention to integrate mobility issues
>> or problems into the Shim6 WG as long as the output are **experimental
>> RFCs**.  However, it may be useful if a twin IRTF is set up to
>> investigate the relation between mobility and multihoming using a shim
>> (or compatible with a shim) so that, in the end, we can output - in a
>> few years and in other WGs - RFCs in the standard track category which
>> bring an answer to both mobility and multihoming.
>>
>>> and I believe to circumvent the IETF direction in the respective
>>> mobility WGs, as end-run as opposed to going to those IETF WGs and
>>> defending their need technically with that IETF center of expertise.
>>
>> The existing mobiliy WGs are not chartered to discuss this.
>>
>> Thierry.
>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Thierry Ernst
>>>> Sent: Wednesday, March 16, 2005 10:35 PM
>>>> To: [email-masked]
>>>> Subject: Re: how mobile do we want to be
>>>>
>>>>
>>>> I'm not sure that Margaret definitions are right. See below.
>>>>
>>>> On Mon, 14 Mar 2005 14:43:31 -0500
>>>> Margaret Wasserman <[email-masked]> wrote:
>>>>> Personally, I consider the subjects of mobility and
>> renumbering to
>>>>>  both be somewhat tangential to the subject of multihoming.
>>>>> Certainly, they are all related in some ways, but they
>> are not the
>>>>>  same problem and may not have the same solution.
>>>>
>>>> There are diffrent topics when we do think about the motivations /
>>>> needs, but that may be similar when thinking about mobility.
>>>> Mobility solutions could serve as a means to
>> renumber/multihome and
>>>> multihoming solutions could serve as a means to solve mobility ...
>>>> So, it's not orthogonal as it depends from which perspective you
>>>> look at  the picture.
>>>>
>>>>> To my way of thinking, the following definitions apply:
>>>>>
>>>>> Mobility:  Changing a node's point of attachment to the
>> Internet
>>>>> without losing L3 sessions. Depending on the mechanism
>> employed,
>>>>> mobility may or may not involve changing the topological
>>>> location of
>>>>> the node within the Internet (i.e. the IP address prefix of
>>>> the node).
>>>>
>>>> "IP-layer mobility" means changing the L3 point of attachment and
>>>> "mobility support" is the abilitiy to do this without losing the
>>>> sessions. Such mobility necessarily means that the
>>>> topological location
>>>> of the node would be changed (if not, I don't understand the
>>>> scenario),
>>>> and, in such a case, that the IP address would be changed (an
>>>> interface
>>>> must obtain an address on the link it is attached to, right
>>>> ?). However,
>>>> depending on the solution to support this, upper layers may
>>>> not see the
>>>> change of IP address (e.g. mobility).
>>>>
>>>>> There are two subtypes of mobility:  mobility within a
>>>> campus (under
>>>>> a single administrative domain) and mobility across the
>> Internet.
>>>>
>>>> This is called Macro/Global mobility and Micro/Local mobility (see
>>>> RFC 3753).
>>>>
>>>>> Mobility within a campus is most often handled by layer 2
>>>> protocols,
>>>>> such as dynamic VLANs, that require no change to the node's
>>>>> topological location (IP prefixes or addresses).  Mobility
>>>> across the
>>>>> Internet does require some change to the topological
>>>> information, at
>>>>> least at some level, and is handled by MIP (v4 or v6).
>>>>
>>>> You can move into a campus and do a L3 handoff between 2 subnets
>>>> (i.e. L3). If the service provider is different, this is "global
>>>> mobility", if
>>>> it's the same provider (2 WLAN, with no L2-bridging) this
>> is "local
>>>> mobility".
>>>>
>>>> L3 mobility can be handled my MIP4/6 if it's a host (or
>> using other
>>>> proprietary management protocols, e.g. LIN6), or by NEMO Basic
>>>> Support if it's a router, or other standardized/not standardized
>>>> mechanisms.
>>>>
>>>>> Renumbering:  Changing a node's topological location within the
>>>>> Internet.  A node that previously had one topological
>> location (IP
>>>>>  address prefix) is reconfigured to have a new topological
>>>>>  location.
>>>>
>>>> Renumbering to me means adversiting a new prefix, with the result
>>>> that the node would have a new IP address. So, I wouldn't say
>>>> "changing the topological location" as the word "changing" bring a
>>>> sense of  "proactive
>>>> behavior" of the node, whereas it is indeed "reactive behavior".
>>>>
>>>> During the process of renumbering, the nodes may be
>>>> "multihomed" during
>>>> a transient period of time.
>>>>
>>>>> Multihoming:  Allowing a node that has more than one
>> topological
>>>>> location within     the Internet to use its redundant paths for
>>>>> efficient or reliable Internet connectivity. Note that
>> multihoming
>>>>>  _does not_ involve changing the node's point(s) of
>>>> attachment to the
>>>>> Internet and/or changing the node's topological locations
>>>> within the
>>>>> Internet; the node has more than one topological location on an
>>>>> ongoing basis.
>>>>
>>>> Agree on this.
>>>>
>>>>> Now, clearly the above definitions are related, particularly if
>>>>> you  view renumbering and mobility as the process of
>> adding a new
>>>>> topological location and removing an old one (perhaps very
>>>> quickly in
>>>>> some situations).  However, there is a very important
>> difference:
>>>>>
>>>>> *** In shim6, two nodes can exchange their full set of
>> topological
>>>>>  locations at the beginning of the session and they are not
>>>>>  expected
>>>>> to change during the lifetime of the session. ***
>>>>>
>>>>> The shim6 mechanism might be a useful tool to soften
>> the blow of
>>>>> renumbering.  A new address prefix (topological
>> location) could be
>>>>>  added, and hosts could be multihomed for a while during which
>>>>> longer-lived connections and associations could be
>> migrated to the
>>>>>  new topological location (manually, or using some other
>>>>>  solution).
>>>>> Then, the old topological information could be deprecated
>>>> and removed
>>>>> on a schedule that allows the completion of shorter lived
>>>>> connections.  So, shim6 is not a renumbering solution, but it
>>>>> might  be usefully applied to the problem of renumbering.
>>>>>
>>>>> It is not easy to see how shim6 (as defined) could apply
>>>> directly to
>>>>> mobility, as described above.  Using shim6 as a
>> mobility mechanism
>>>>>  would (at minimum) involve adding new topological
>> information in
>>>>> mid-session and might involve adding new topological
>>>> information at a
>>>>> time when the node is unreachable using the old topological
>>>>> information.  This creates a universe of protocol issues
>>>> and security
>>>>> concerns that are not present in the simpler multihoming
>>>> case, and I
>>>>> would prefer that we don't try to solve this problem
>> right now as
>>>>> part of the shim6 solution.
>>>>
>>>> I agree that it's not straight forward to see shim6 applying for
>>>> mobility, but I think that what Avri was trying to say is
>>>> that it would
>>>> be a shame if such an important change wouldn't at the same time
>>>> bring an answer to the mobility issue (particularly given the fact
>>>> that an important proportion of nodes would be mobile).
>>>>
>>>> So, playing an evil game, mobility-concerned people may
>> wonder what
>>>> is the benefit of such an architectural changes if the mobility
>>>> problem remain unchanged ? (does it worth the effort ?).
>>>>
>>>> Thierry.
>>>>
>>>>
>>>>> Personally, I respect all of the work that has gone into the
>>>>> Mobile  IP solutions, and I think that we would be
>> underestimating
>>>>> the  difficulty and subtlety of that problem space if we assume
>>>>> that it  can be solved by a simple variant of the shim6
>> approach.
>>>>> I
>>>> do think
>>>>> it is important for shim6 to co-exist peacefully with MIPv4 and
>>>>> v6,  and I think that is sufficient, at least for our
>> first step.
>>>>
>>>>
>>
>>
>

Delivery-date: Thu, 17 Mar 2005 15:08:04 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Thu, 17 Mar 2005 16:07:31 +0100
To: Thierry Ernst <[email-masked]>

Hi Thierry,

El 17/03/2005, a las 3:28, Thierry Ernst escribió:

>
> Dear all,
>
> I attended half the BOF, but couldn't stay until the end as I had to
> take my flight, so, sorry if I raise issues which was discussed in the
> BOF.
>
> First, I agree with what Avri said during the BOF - that there is an
> opportunity window and that we may be losing a good opportunity to 
> solve
> once for all the mobility problem if we don't investigate it further.
>
> However, I'm not sure it should be the purpose of the Shim6 WG as my
> understanding is that it would produce Experimental RFCs,

Maybe i missed something here, but i don't recall that the goal of shim 
was to produce exprimental RFCs, i guess we are here to produce 
standards tracks.

Chairs?

Regards, marcelo

> so I would
> find myself satisfied in this situation, provied mobility is
> investigated at the IETF.
>
> Iljitsch van Beijnum <[email-masked]> wrote:
>> On 14-mrt-05, at 16:41, [email-masked] wrote:
>>
>>> I think the question is more a recognition that the network is now a
>>>  network in motion:  systems move and networks move.  And while it
>>>  is
>>> true that some part so the network, doesn't move, or moves very
>>> slowly, an overwhelming amount of the edge is in motion. And I think
>>>  it is important to realize that a large number of  sessions should
>>> remain viable despite this continuous motion.
>
>> Could you provide some examples of applications where a
>> disconnect/reconnect is sufficiently problematic that MIPv6 or
>> something similar is warranted?
>>
>> So far the only stuff I can think of is remote login and streaming
>> audio/video.
>
> First, I've a question for Avri. What do you mean by "network in
> motion", is this the mobile networks that we are supporting in the NEMO
> WG, or something else ? (I would say yes, but since you didn't mention
> NEMO, I cannot be sure).
>
> If NEMO scenarios are in mind, I would second Avri in saying that a
> significant part of the Internet nodes would be "mobile" (either that
> change their point of attachment [i.e. mobile host or mobile routers] 
> or
> they are located in a network which "gateway" is mobile).
>
> Basically, MIP6 bring a solution to the former, and NEMO BS to the
> latter (thought NEMO BS is not providing routing optimization). That's
> not the point. The point is that if Shinm6 is looking into a solution
> which would require a major architectural change, then, yes, it would
> make sense that this major architectural change takes mobility
> explicitly into consideration. Here, I do agree with Avri.
>
> A conclusion might be that Shim6 is a little bit immature to be set up
> at the IETF, whereas a IRFT WG on that (taking mobility into
> consideration) might make more sense.
>
>>> In other words I think the question is not, "how mobile do we want
>>> to  be", but how mobile are we and how mobile will we be by the time
>>> a  shim6 solution is implemented and widely deployed.
>>
>> My prediction: not very. 99% of all traffic today is either sessions
>> that go away within seconds, or can be easily reestablished after a
>> forced disconnect. I don't see how the other 1% is going to take over
>> the world any time soon.
>
> Hold on, if we only have 1% of mobile nodes today, it may be because 
> the
> Internet is not tuned for mobility, and that IPv6 is not yet deployed.
> IPv6 is a change to deploy neew usages, and most of these new usages
> will be mobile (see my comment about who is mobile ealier in my mail).
> Every human will have a mobile phone, and possibly, many millions of
> them will carry a PAN (ako NEMO). All cars will have an embedded 
> network
> (and that could be NEMO too). That's a few hundred millions cars.
>
> This will happen by the time the Shim6 solution is deployed (if it can
> be deployed, which I'm not sure it would if mobility is not 
> considered).
>
>
>>> It is for these reasons that I am arguing so insistently that we
>>> must  include systems and networks in motion (if we want to reserve
>>> the term  mobility for MIP4/6 to avoid confusion) as part of the
>>> problem space  shim6 must take into account.
>>
>> I don't think this is a good idea. Let's focus on the basic shim
>> functionality, and when we have something useful there, we can sync up
>>  with other efforts and see what we need to do to avoid duplication of
>>
>> effort and to gain synergy.
>
> Why this had to be done at the IETF ? (I'm just asking, not opposing,
> and, in summary, my concern is that mobility should be investigated one
> place or another if a Shim6 solution is ever expected to be deployed).
>
> Thierry.
>
>

Delivery-date: Thu, 17 Mar 2005 14:17:58 +0000
Date: Thu, 17 Mar 2005 09:14:15 -0500
To: Thierry Ernst <[email-masked]>, [email-masked]
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be

Hi Thierry,

At 12:35 PM +0900 3/17/05, Thierry Ernst wrote:
>There are diffrent topics when we do think about the motivations /
>needs, but that may be similar when thinking about mobility. Mobility
>solutions could serve as a means to renumber/multihome and multihoming
>solutions could serve as a means to solve mobility ... So, it's not
>orthogonal as it depends from which perspective you look at the picture.

I did not say that the definitions of mobility, renumbering and 
multihoming are orthogonal (i.e. completely independent).  I said 
that they are tangential (somewhat related).

>"IP-layer mobility" means changing the L3 point of attachment and
>"mobility support" is the abilitiy to do this without losing the
>sessions. Such mobility necessarily means that the topological location
>of the node would be changed (if not, I don't understand the scenario),
>and, in such a case, that the IP address would be changed (an interface
>must obtain an address on the link it is attached to, right ?). However,
>depending on the solution to support this, upper layers may not see the
>change of IP address (e.g. mobility).

I am not sure that the world-at-large has accepted your definition of 
the term "mobility" to apply only to those cases when a node moves 
from one IP subnet to another.  In a large bridged/VLAN network, a 
host can move about freely (even between buildings) without changing 
it's location in the L3 topology, through the use of dynamic VLANs or 
other L2 mobility solutions.  The node's IP address doesn't change, 
and no L3 mobility solution is needed to reach it.  In fact, the L3 
protocols are unaware that the node has moved.

Another case where mobility is handled at L2 (at least from the 
perspective of the top-level IP layer) is 3GPP.  The mobility of the 
node is handled by the 3GPP network, not by an IP-layer mobility 
solution.

>>  There are two subtypes of mobility:  mobility within a campus (under
>>  a single administrative domain) and mobility across the Internet.
>
>This is called Macro/Global mobility and Micro/Local mobility (see RFC
>3753).

Okay.

>>  Mobility within a campus is most often handled by layer 2 protocols,
>>  such as dynamic VLANs, that require no change to the node's
>>  topological location (IP prefixes or addresses).  Mobility across the
>>  Internet does require some change to the topological information, at
>>  least at some level, and is handled by MIP (v4 or v6).
>
>You can move into a campus and do a L3 handoff between 2 subnets (i.e.
>L3). If the service provider is different, this is "global mobility", if
>it's the same provider (2 WLAN, with no L2-bridging) this is "local
>mobility".

You can also move within a campus/administrative domain with no L3 
handoff at all, assuming that there are L2 mechanisms to support this.

>>  Multihoming:  Allowing a node that has more than one topological
>>  location within     the Internet to use its redundant paths for
>>  efficient or reliable Internet connectivity. Note that multihoming
>>  _does not_ involve changing the node's point(s) of attachment to the
>>  Internet and/or changing the node's topological locations within the
>>  Internet; the node has more than one topological location on an
>>  ongoing basis.
>
>I agree that it's not straight forward to see shim6 applying for
>mobility, but I think that what Avri was trying to say is that it would
>be a shame if such an important change wouldn't at the same time bring
>an answer to the mobility issue (particularly given the fact that an
>important proportion of nodes would be mobile).

I believe that I understand Avri's position.  I just don't happen to 
agree with it.

Part of my disagreement lies in the assumption that an important 
proportion of the nodes will be mobile, where "mobile" is defined as 
changing their location in the L3 topology while retaining active L4 
sessions.  While I agree that an important number of nodes will move 
about (laptops, cell phones, etc.), I do not expect that a 
particularly large portion of the nodes will be mobile at L3 
(changing their location in the L3 topology) while expecting (or even 
wanting) L4 sessions to remain active.

We already have solutions for those nodes or networks that do need 
true mobility, as defined in the previous paragraph: MIP* & NEMO.

What we don't have is a scalable multi-homing solution.

>So, playing an evil game, mobility-concerned people may wonder what is
>the benefit of such an architectural changes if the mobility problem
>remain unchanged ? (does it worth the effort ?).

The benefit is that it solves the scalable multihoming problem, and 
some of us consider that an important problem to solve.

Margaret

Delivery-date: Thu, 17 Mar 2005 09:11:12 +0000
Date: Thu, 17 Mar 2005 11:10:45 +0200 (EET)
From: Kurtis Lindqvist <[email-masked]>
To: Jeroen Massar <[email-masked]>
Cc: [email-masked], Leif Johansson <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Pasi Sarolahti <[email-masked]>, "Bound, Jim" <[email-masked]>
Subject: RE: shim - transport/app communication

On Wed, 16 Mar 2005, Jeroen Massar wrote:
> supports IPv6 addresses, though I have to note that shim6 should be
> named 'shim', as this trick can also work for IPv4 and then they would
> not even need IPv6 for that matter. But the minimal requirement we could
> set is "use a getaddrinfo() loop to cycle through all the addresses",
> the ULID magic can be put in the getaddrinfo() function which returns
> ULID's instead of the routing IP's.

This was brought up in the BOF as well. We have never had as a charter
item in multi6 (the work shim6 builds on) do work on solutions for IPv4.
If we where to address that as well, that would be a question for the ADs
to discuss. However, I think we should focus on making this work for v6
first, that will keep us busy enough...

- kurtis -

Delivery-date: Thu, 17 Mar 2005 05:17:13 +0000
Date: Thu, 17 Mar 2005 14:21:37 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

> > May I suggest a compromise view here.  Why don't we fix/focus on the
> > multihoming problem.  In the course of that work we should do
> > nothing to hurt mobility as we must always think about security in
> > the IETF work effort. If there is a mobility solution in our result
> > it will  be evident to all.  
> 
> Generally, I agree. I think using shims for multihoming generally
> seems to me to be an engineering problem, while trying to apply them
> for mobility seems to veer off into research territory.  I talked to
> many people in the hallways about the interrelation between
> multihoming and mobility; this sounds like fodder for a bof in Paris /
> Vancouver.  

I disagree a BOF is needed, what is needed is to tackled with this
specific problem at the **IRTF**. There are more mature topics on which
IETF WGs have been (wrongly) disapproved while this is pretty straight
forward to me that it should be IRTF in the present case.

> I'd strongly suggest that we focus on getting the shim work going
> forward for multihoming and revisit the relationship between
> multihoming & mobility seperately.  We (the IETF) are much better
> focusing on a single problem space.

I prefer what was suggested by Jim, with explicit mention in the Shim6
charter.

Thierry.

Delivery-date: Thu, 17 Mar 2005 05:09:59 +0000
Date: Thu, 17 Mar 2005 14:14:19 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

> May I suggest a compromise view here.  Why don't we fix/focus on the
> multihoming problem.  In the course of that work we should do nothing
> to hurt mobility as we must always think about security in the IETF
> work effort. If there is a mobility solution in our result it will be
> evident to all.  

I agree with this to the condition it is written in the charter.

> I see better where your going from the mail below.  
I hope that I succeeded into this.

> I just believe we must remain focused on the multihoming problem.  

I agree on this too.

Thierry

> I am already
> extremely skeptical of shims first off as network experienced
> implementor and architect and one who ships products, if we try to
> solve mobility too I will probably go away.  Not because its not
> interesting/important, but the engineer and leader part of my brain
> would be telling me this effort will not complete trying to solve both
> abstractions at the same time and consensus will not happen.  Thus not
> a good use of my precious time, life, and my eyes that read so many
> IETF drafts etc.
> 
> thanks
> /jim
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Thierry Ernst
> > Sent: Wednesday, March 16, 2005 11:46 PM
> > To: [email-masked]
> > Subject: Re: how mobile do we want to be
> > 
> > 
> > > I will take it further.  Margaret is correct and I will be
> > > stronger and replace the word tangential with orthogonal. 
> > > Mobility and Multihoming are completely two separate technology
> > > efforts and functions related to building a multihome
> > > archictecture, a network operations model for an enterprise, or a
> > > shim solution within an IP stack. 
> > 
> > The motiviations behind mobility and multihoming are distinct 
> > (i.e. the
> > intention is orthogonal) but the solutions MAY be similar / could
> > apply to one another / could be the same (i.e. the result may not be
> > orthogonal).
> > 
> > > Another example is Mobile IPv6 et al (multiple working groups
> > > on mobility) is completely orthogonal to MANETs problem of 
> > routing or
> > > autoconfiguratin on the link.
> > > 
> > > 
> > > In my opinion I have seen some views expressed to try to integrate
> > > Mobility issues-problems-opportunities into the work of
> > > multihoming
> > 
> > I'm not sure it's the intention. I would better take this as 
> > a "concern"
> > (deploying an architectural change which doesn't solve the mobility
> > problem is at best a loss of opportunity and at worse a lack of
> > planning) . I personaly have no intention to integrate mobility
> > issues or problems into the Shim6 WG as long as the output are
> > **experimental RFCs**.  However, it may be useful if a twin IRTF is
> > set up to investigate the relation between mobility and multihoming
> > using a shim (or compatible with a shim) so that, in the end, we can
> > output - in a few years and in other WGs - RFCs in the standard
> > track category which bring an answer to both mobility and
> > multihoming. 
> > 
> > > and I believe to circumvent the IETF direction in the respective
> > > mobility WGs, as end-run as opposed to going to those IETF WGs and
> > > defending their need technically with that IETF center of
> > > expertise.
> > 
> > The existing mobiliy WGs are not chartered to discuss this.
> > 
> > Thierry.
> >  
> > > /jim 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On 
> > > > Behalf Of Thierry Ernst
> > > > Sent: Wednesday, March 16, 2005 10:35 PM
> > > > To: [email-masked]
> > > > Subject: Re: how mobile do we want to be
> > > > 
> > > > 
> > > > I'm not sure that Margaret definitions are right. See below.
> > > > 
> > > > On Mon, 14 Mar 2005 14:43:31 -0500
> > > > Margaret Wasserman <[email-masked]> wrote: 
> > > > > Personally, I consider the subjects of mobility and 
> > renumbering to
> > > > >  both be somewhat tangential to the subject of multihoming. 
> > > > > Certainly, they are all related in some ways, but they 
> > are not the
> > > > >  same problem and may not have the same solution.
> > > > 
> > > > There are diffrent topics when we do think about the motivations
> > > > / needs, but that may be similar when thinking about mobility.
> > > > Mobility solutions could serve as a means to 
> > renumber/multihome and
> > > > multihoming solutions could serve as a means to solve mobility
> > > > ... So, it's not orthogonal as it depends from which perspective
> > > > you look at  the picture.
> > > > 
> > > > > To my way of thinking, the following definitions apply:
> > > > > 
> > > > > Mobility:  Changing a node's point of attachment to the 
> > Internet 
> > > > > without losing L3 sessions. Depending on the mechanism 
> > employed, 
> > > > > mobility may or may not involve changing the topological 
> > > > location of 
> > > > > the node within the Internet (i.e. the IP address prefix of 
> > > > the node).
> > > > 
> > > > "IP-layer mobility" means changing the L3 point of attachment
> > > > and "mobility support" is the abilitiy to do this without losing
> > > > the sessions. Such mobility necessarily means that the 
> > > > topological location
> > > > of the node would be changed (if not, I don't understand the 
> > > > scenario),
> > > > and, in such a case, that the IP address would be changed (an 
> > > > interface
> > > > must obtain an address on the link it is attached to, right 
> > > > ?). However,
> > > > depending on the solution to support this, upper layers may 
> > > > not see the
> > > > change of IP address (e.g. mobility).
> > > > 
> > > > > There are two subtypes of mobility:  mobility within a 
> > > > campus (under 
> > > > > a single administrative domain) and mobility across the 
> > Internet. 
> > > > 
> > > > This is called Macro/Global mobility and Micro/Local mobility
> > > > (see RFC 3753).
> > > > 
> > > > > Mobility within a campus is most often handled by layer 2 
> > > > protocols, 
> > > > > such as dynamic VLANs, that require no change to the node's 
> > > > > topological location (IP prefixes or addresses).  Mobility 
> > > > across the 
> > > > > Internet does require some change to the topological 
> > > > information, at 
> > > > > least at some level, and is handled by MIP (v4 or v6).
> > > > 
> > > > You can move into a campus and do a L3 handoff between 2 subnets
> > > > (i.e. L3). If the service provider is different, this is "global
> > > >  mobility", if
> > > > it's the same provider (2 WLAN, with no L2-bridging) this 
> > is "local
> > > > mobility".
> > > > 
> > > > L3 mobility can be handled my MIP4/6 if it's a host (or 
> > using other
> > > > proprietary management protocols, e.g. LIN6), or by NEMO Basic
> > > > Support if it's a router, or other standardized/not standardized
> > > > mechanisms.
> > > >  
> > > > > Renumbering:  Changing a node's topological location within
> > > > > the  Internet.  A node that previously had one topological 
> > location (IP
> > > > >  address prefix) is reconfigured to have a new topological
> > > > >  location.
> > > > 
> > > > Renumbering to me means adversiting a new prefix, with the
> > > > result that the node would have a new IP address. So, I wouldn't
> > > > say "changing the topological location" as the word "changing"
> > > > bring a sense of  "proactive
> > > > behavior" of the node, whereas it is indeed "reactive behavior".
> > > > 
> > > > During the process of renumbering, the nodes may be 
> > > > "multihomed" during
> > > > a transient period of time.
> > > > 
> > > > > Multihoming:  Allowing a node that has more than one 
> > topological 
> > > > > location within     the Internet to use its redundant paths
> > > > > for  efficient or reliable Internet connectivity. Note that 
> > multihoming
> > > > >  _does not_ involve changing the node's point(s) of 
> > > > attachment to the 
> > > > > Internet and/or changing the node's topological locations 
> > > > within the 
> > > > > Internet; the node has more than one topological location on
> > > > > an  ongoing basis.
> > > > 
> > > > Agree on this.
> > > >  
> > > > > Now, clearly the above definitions are related, particularly
> > > > > if you  view renumbering and mobility as the process of 
> > adding a new 
> > > > > topological location and removing an old one (perhaps very 
> > > > quickly in 
> > > > > some situations).  However, there is a very important 
> > difference:
> > > > > 
> > > > > *** In shim6, two nodes can exchange their full set of 
> > topological
> > > > >  locations at the beginning of the session and they are not
> > > > >  expected 
> > > > > to change during the lifetime of the session. ***
> > > > > 
> > > > > The shim6 mechanism might be a useful tool to soften 
> > the blow of 
> > > > > renumbering.  A new address prefix (topological 
> > location) could be
> > > > >  added, and hosts could be multihomed for a while during which
> > > > >  
> > > > > longer-lived connections and associations could be 
> > migrated to the
> > > > >  new topological location (manually, or using some other
> > > > >  solution). 
> > > > > Then, the old topological information could be deprecated 
> > > > and removed 
> > > > > on a schedule that allows the completion of shorter lived 
> > > > > connections.  So, shim6 is not a renumbering solution, but it
> > > > > might  be usefully applied to the problem of renumbering.
> > > > > 
> > > > > It is not easy to see how shim6 (as defined) could apply 
> > > > directly to 
> > > > > mobility, as described above.  Using shim6 as a 
> > mobility mechanism
> > > > >  would (at minimum) involve adding new topological 
> > information in 
> > > > > mid-session and might involve adding new topological 
> > > > information at a 
> > > > > time when the node is unreachable using the old topological 
> > > > > information.  This creates a universe of protocol issues 
> > > > and security 
> > > > > concerns that are not present in the simpler multihoming 
> > > > case, and I 
> > > > > would prefer that we don't try to solve this problem 
> > right now as 
> > > > > part of the shim6 solution.
> > > > 
> > > > I agree that it's not straight forward to see shim6 applying for
> > > > mobility, but I think that what Avri was trying to say is 
> > > > that it would
> > > > be a shame if such an important change wouldn't at the same time
> > > > bring an answer to the mobility issue (particularly given the
> > > > fact that an important proportion of nodes would be mobile).
> > > > 
> > > > So, playing an evil game, mobility-concerned people may 
> > wonder what
> > > > is the benefit of such an architectural changes if the mobility
> > > > problem remain unchanged ? (does it worth the effort ?).
> > > > 
> > > > Thierry.
> > > > 
> > > > 
> > > > > Personally, I respect all of the work that has gone into the
> > > > > Mobile  IP solutions, and I think that we would be 
> > underestimating
> > > > > the  difficulty and subtlety of that problem space if we
> > > > > assume that it  can be solved by a simple variant of the shim6
> > > > > 
> > approach. 
> > > > > I 
> > > > do think 
> > > > > it is important for shim6 to co-exist peacefully with MIPv4
> > > > > and v6,  and I think that is sufficient, at least for our 
> > first step.
> > > > 
> > > > 
> > 
> > 

-- 
Thierry Ernst, PhD
WIDE, Jun Murai Lab., Keio University, Japan
Nautilus6 Chair: http://www.nautilus6.org
Web: http://www.sfc.wide.ad.jp/~ernst/
T:+81-44-580-1600 F:+81-44-580-1437
--

Delivery-date: Thu, 17 Mar 2005 05:08:08 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Thu, 17 Mar 2005 07:06:34 +0200
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Jim,

> May I suggest a compromise view here.  Why don't we fix/focus on the
> multihoming problem.  In the course of that work we should do nothing to
> hurt mobility as we must always think about security in the IETF work
> effort. If there is a mobility solution in our result it will 
> be evident to all.  

Generally, I agree. I think using shims for multihoming generally seems
to me to be an engineering problem, while trying to apply them for
mobility seems to veer off into research territory.  I talked to many
people in the hallways about the interrelation between multihoming and
mobility; this sounds like fodder for a bof in Paris / Vancouver.  

I'd strongly suggest that we focus on getting the shim work going forward
for multihoming and revisit the relationship between multihoming & mobility
seperately.  We (the IETF) are much better focusing on a single problem
space.

John

Delivery-date: Thu, 17 Mar 2005 05:07:02 +0000
Date: Thu, 17 Mar 2005 16:06:24 +1100
To: "Bound, Jim" <[email-masked]>, "Thierry Ernst" <[email-masked]>, <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: RE: how mobile do we want to be

At 03:55 PM 17/03/2005, Bound, Jim wrote:
>May I suggest a compromise view here.  Why don't we fix/focus on the
>multihoming problem.

YYes, indeed, that was the plan as I understood it.

>  In the course of that work we should do nothing to
>hurt mobility as we must always think about security in the IETF work
>effort.

Exactly  - I think we might want to reassure ourselves that a home agent 
can exist in a multi-homed network, and then look at the issue of a host 
roaming into a multi-home3d environment.

All good points Jim

  regards,

     Geoff

>If there is a mobility solution in our result it will be evident
>to all.  I see better where your going from the mail below.  I just
>believe we must remain focused on the multihoming problem.  I am already
>extremely skeptical of shims first off as network experienced
>implementor and architect and one who ships products, if we try to solve
>mobility too I will probably go away.  Not because its not
>interesting/important, but the engineer and leader part of my brain
>would be telling me this effort will not complete trying to solve both
>abstractions at the same time and consensus will not happen.  Thus not a
>good use of my precious time, life, and my eyes that read so many IETF
>drafts etc.
>
>thanks
>/jim
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Thierry Ernst
> > Sent: Wednesday, March 16, 2005 11:46 PM
> > To: [email-masked]
> > Subject: Re: how mobile do we want to be
> >
> >
> > > I will take it further.  Margaret is correct and I will be stronger
> > > and replace the word tangential with orthogonal.  Mobility and
> > > Multihoming are completely two separate technology efforts and
> > > functions related to building a multihome archictecture, a network
> > > operations model for an enterprise, or a shim solution within an IP
> > > stack.
> >
> > The motiviations behind mobility and multihoming are distinct
> > (i.e. the
> > intention is orthogonal) but the solutions MAY be similar / could
> > apply to one another / could be the same (i.e. the result may not be
> > orthogonal).
> >
> > > Another example is Mobile IPv6 et al (multiple working groups
> > > on mobility) is completely orthogonal to MANETs problem of
> > routing or
> > > autoconfiguratin on the link.
> > >
> > >
> > > In my opinion I have seen some views expressed to try to integrate
> > > Mobility issues-problems-opportunities into the work of multihoming
> >
> > I'm not sure it's the intention. I would better take this as
> > a "concern"
> > (deploying an architectural change which doesn't solve the mobility
> > problem is at best a loss of opportunity and at worse a lack of
> > planning) . I personaly have no intention to integrate mobility issues
> > or problems into the Shim6 WG as long as the output are **experimental
> > RFCs**.  However, it may be useful if a twin IRTF is set up to
> > investigate the relation between mobility and multihoming using a shim
> > (or compatible with a shim) so that, in the end, we can output - in a
> > few years and in other WGs - RFCs in the standard track category which
> > bring an answer to both mobility and multihoming.
> >
> > > and I believe to circumvent the IETF direction in the respective
> > > mobility WGs, as end-run as opposed to going to those IETF WGs and
> > > defending their need technically with that IETF center of expertise.
> >
> > The existing mobiliy WGs are not chartered to discuss this.
> >
> > Thierry.
> >
> > > /jim
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of Thierry Ernst
> > > > Sent: Wednesday, March 16, 2005 10:35 PM
> > > > To: [email-masked]
> > > > Subject: Re: how mobile do we want to be
> > > >
> > > >
> > > > I'm not sure that Margaret definitions are right. See below.
> > > >
> > > > On Mon, 14 Mar 2005 14:43:31 -0500
> > > > Margaret Wasserman <[email-masked]> wrote:
> > > > > Personally, I consider the subjects of mobility and
> > renumbering to
> > > > >  both be somewhat tangential to the subject of multihoming.
> > > > > Certainly, they are all related in some ways, but they
> > are not the
> > > > >  same problem and may not have the same solution.
> > > >
> > > > There are diffrent topics when we do think about the motivations /
> > > > needs, but that may be similar when thinking about mobility.
> > > > Mobility solutions could serve as a means to
> > renumber/multihome and
> > > > multihoming solutions could serve as a means to solve mobility ...
> > > > So, it's not orthogonal as it depends from which perspective you
> > > > look at  the picture.
> > > >
> > > > > To my way of thinking, the following definitions apply:
> > > > >
> > > > > Mobility:  Changing a node's point of attachment to the
> > Internet
> > > > > without losing L3 sessions. Depending on the mechanism
> > employed,
> > > > > mobility may or may not involve changing the topological
> > > > location of
> > > > > the node within the Internet (i.e. the IP address prefix of
> > > > the node).
> > > >
> > > > "IP-layer mobility" means changing the L3 point of attachment and
> > > > "mobility support" is the abilitiy to do this without losing the
> > > > sessions. Such mobility necessarily means that the
> > > > topological location
> > > > of the node would be changed (if not, I don't understand the
> > > > scenario),
> > > > and, in such a case, that the IP address would be changed (an
> > > > interface
> > > > must obtain an address on the link it is attached to, right
> > > > ?). However,
> > > > depending on the solution to support this, upper layers may
> > > > not see the
> > > > change of IP address (e.g. mobility).
> > > >
> > > > > There are two subtypes of mobility:  mobility within a
> > > > campus (under
> > > > > a single administrative domain) and mobility across the
> > Internet.
> > > >
> > > > This is called Macro/Global mobility and Micro/Local mobility (see
> > > > RFC 3753).
> > > >
> > > > > Mobility within a campus is most often handled by layer 2
> > > > protocols,
> > > > > such as dynamic VLANs, that require no change to the node's
> > > > > topological location (IP prefixes or addresses).  Mobility
> > > > across the
> > > > > Internet does require some change to the topological
> > > > information, at
> > > > > least at some level, and is handled by MIP (v4 or v6).
> > > >
> > > > You can move into a campus and do a L3 handoff between 2 subnets
> > > > (i.e. L3). If the service provider is different, this is "global
> > > > mobility", if
> > > > it's the same provider (2 WLAN, with no L2-bridging) this
> > is "local
> > > > mobility".
> > > >
> > > > L3 mobility can be handled my MIP4/6 if it's a host (or
> > using other
> > > > proprietary management protocols, e.g. LIN6), or by NEMO Basic
> > > > Support if it's a router, or other standardized/not standardized
> > > > mechanisms.
> > > >
> > > > > Renumbering:  Changing a node's topological location within the
> > > > > Internet.  A node that previously had one topological
> > location (IP
> > > > >  address prefix) is reconfigured to have a new topological
> > > > >  location.
> > > >
> > > > Renumbering to me means adversiting a new prefix, with the result
> > > > that the node would have a new IP address. So, I wouldn't say
> > > > "changing the topological location" as the word "changing" bring a
> > > > sense of  "proactive
> > > > behavior" of the node, whereas it is indeed "reactive behavior".
> > > >
> > > > During the process of renumbering, the nodes may be
> > > > "multihomed" during
> > > > a transient period of time.
> > > >
> > > > > Multihoming:  Allowing a node that has more than one
> > topological
> > > > > location within     the Internet to use its redundant paths for
> > > > > efficient or reliable Internet connectivity. Note that
> > multihoming
> > > > >  _does not_ involve changing the node's point(s) of
> > > > attachment to the
> > > > > Internet and/or changing the node's topological locations
> > > > within the
> > > > > Internet; the node has more than one topological location on an
> > > > > ongoing basis.
> > > >
> > > > Agree on this.
> > > >
> > > > > Now, clearly the above definitions are related, particularly if
> > > > > you  view renumbering and mobility as the process of
> > adding a new
> > > > > topological location and removing an old one (perhaps very
> > > > quickly in
> > > > > some situations).  However, there is a very important
> > difference:
> > > > >
> > > > > *** In shim6, two nodes can exchange their full set of
> > topological
> > > > >  locations at the beginning of the session and they are not
> > > > >  expected
> > > > > to change during the lifetime of the session. ***
> > > > >
> > > > > The shim6 mechanism might be a useful tool to soften
> > the blow of
> > > > > renumbering.  A new address prefix (topological
> > location) could be
> > > > >  added, and hosts could be multihomed for a while during which
> > > > > longer-lived connections and associations could be
> > migrated to the
> > > > >  new topological location (manually, or using some other
> > > > >  solution).
> > > > > Then, the old topological information could be deprecated
> > > > and removed
> > > > > on a schedule that allows the completion of shorter lived
> > > > > connections.  So, shim6 is not a renumbering solution, but it
> > > > > might  be usefully applied to the problem of renumbering.
> > > > >
> > > > > It is not easy to see how shim6 (as defined) could apply
> > > > directly to
> > > > > mobility, as described above.  Using shim6 as a
> > mobility mechanism
> > > > >  would (at minimum) involve adding new topological
> > information in
> > > > > mid-session and might involve adding new topological
> > > > information at a
> > > > > time when the node is unreachable using the old topological
> > > > > information.  This creates a universe of protocol issues
> > > > and security
> > > > > concerns that are not present in the simpler multihoming
> > > > case, and I
> > > > > would prefer that we don't try to solve this problem
> > right now as
> > > > > part of the shim6 solution.
> > > >
> > > > I agree that it's not straight forward to see shim6 applying for
> > > > mobility, but I think that what Avri was trying to say is
> > > > that it would
> > > > be a shame if such an important change wouldn't at the same time
> > > > bring an answer to the mobility issue (particularly given the fact
> > > > that an important proportion of nodes would be mobile).
> > > >
> > > > So, playing an evil game, mobility-concerned people may
> > wonder what
> > > > is the benefit of such an architectural changes if the mobility
> > > > problem remain unchanged ? (does it worth the effort ?).
> > > >
> > > > Thierry.
> > > >
> > > >
> > > > > Personally, I respect all of the work that has gone into the
> > > > > Mobile  IP solutions, and I think that we would be
> > underestimating
> > > > > the  difficulty and subtlety of that problem space if we assume
> > > > > that it  can be solved by a simple variant of the shim6
> > approach.
> > > > > I
> > > > do think
> > > > > it is important for shim6 to co-exist peacefully with MIPv4 and
> > > > > v6,  and I think that is sufficient, at least for our
> > first step.
> > > >
> > > >
> >
> >

Delivery-date: Thu, 17 Mar 2005 04:55:46 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Wed, 16 Mar 2005 23:55:37 -0500
From: "Bound, Jim" <[email-masked]>
To: "Thierry Ernst" <[email-masked]>, <[email-masked]>

May I suggest a compromise view here.  Why don't we fix/focus on the
multihoming problem.  In the course of that work we should do nothing to
hurt mobility as we must always think about security in the IETF work
effort. If there is a mobility solution in our result it will be evident
to all.  I see better where your going from the mail below.  I just
believe we must remain focused on the multihoming problem.  I am already
extremely skeptical of shims first off as network experienced
implementor and architect and one who ships products, if we try to solve
mobility too I will probably go away.  Not because its not
interesting/important, but the engineer and leader part of my brain
would be telling me this effort will not complete trying to solve both
abstractions at the same time and consensus will not happen.  Thus not a
good use of my precious time, life, and my eyes that read so many IETF
drafts etc.

thanks
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thierry Ernst
> Sent: Wednesday, March 16, 2005 11:46 PM
> To: [email-masked]
> Subject: Re: how mobile do we want to be
> 
> 
> > I will take it further.  Margaret is correct and I will be stronger
> > and replace the word tangential with orthogonal.  Mobility and
> > Multihoming are completely two separate technology efforts and
> > functions related to building a multihome archictecture, a network
> > operations model for an enterprise, or a shim solution within an IP
> > stack. 
> 
> The motiviations behind mobility and multihoming are distinct 
> (i.e. the
> intention is orthogonal) but the solutions MAY be similar / could
> apply to one another / could be the same (i.e. the result may not be
> orthogonal).
> 
> > Another example is Mobile IPv6 et al (multiple working groups
> > on mobility) is completely orthogonal to MANETs problem of 
> routing or
> > autoconfiguratin on the link.
> > 
> > 
> > In my opinion I have seen some views expressed to try to integrate
> > Mobility issues-problems-opportunities into the work of multihoming
> 
> I'm not sure it's the intention. I would better take this as 
> a "concern"
> (deploying an architectural change which doesn't solve the mobility
> problem is at best a loss of opportunity and at worse a lack of
> planning) . I personaly have no intention to integrate mobility issues
> or problems into the Shim6 WG as long as the output are **experimental
> RFCs**.  However, it may be useful if a twin IRTF is set up to
> investigate the relation between mobility and multihoming using a shim
> (or compatible with a shim) so that, in the end, we can output - in a
> few years and in other WGs - RFCs in the standard track category which
> bring an answer to both mobility and multihoming. 
> 
> > and I believe to circumvent the IETF direction in the respective
> > mobility WGs, as end-run as opposed to going to those IETF WGs and
> > defending their need technically with that IETF center of expertise.
> 
> The existing mobiliy WGs are not chartered to discuss this.
> 
> Thierry.
>  
> > /jim 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Thierry Ernst
> > > Sent: Wednesday, March 16, 2005 10:35 PM
> > > To: [email-masked]
> > > Subject: Re: how mobile do we want to be
> > > 
> > > 
> > > I'm not sure that Margaret definitions are right. See below.
> > > 
> > > On Mon, 14 Mar 2005 14:43:31 -0500
> > > Margaret Wasserman <[email-masked]> wrote: 
> > > > Personally, I consider the subjects of mobility and 
> renumbering to
> > > >  both be somewhat tangential to the subject of multihoming. 
> > > > Certainly, they are all related in some ways, but they 
> are not the
> > > >  same problem and may not have the same solution.
> > > 
> > > There are diffrent topics when we do think about the motivations /
> > > needs, but that may be similar when thinking about mobility.
> > > Mobility solutions could serve as a means to 
> renumber/multihome and
> > > multihoming solutions could serve as a means to solve mobility ...
> > > So, it's not orthogonal as it depends from which perspective you
> > > look at  the picture.
> > > 
> > > > To my way of thinking, the following definitions apply:
> > > > 
> > > > Mobility:  Changing a node's point of attachment to the 
> Internet 
> > > > without losing L3 sessions. Depending on the mechanism 
> employed, 
> > > > mobility may or may not involve changing the topological 
> > > location of 
> > > > the node within the Internet (i.e. the IP address prefix of 
> > > the node).
> > > 
> > > "IP-layer mobility" means changing the L3 point of attachment and
> > > "mobility support" is the abilitiy to do this without losing the
> > > sessions. Such mobility necessarily means that the 
> > > topological location
> > > of the node would be changed (if not, I don't understand the 
> > > scenario),
> > > and, in such a case, that the IP address would be changed (an 
> > > interface
> > > must obtain an address on the link it is attached to, right 
> > > ?). However,
> > > depending on the solution to support this, upper layers may 
> > > not see the
> > > change of IP address (e.g. mobility).
> > > 
> > > > There are two subtypes of mobility:  mobility within a 
> > > campus (under 
> > > > a single administrative domain) and mobility across the 
> Internet. 
> > > 
> > > This is called Macro/Global mobility and Micro/Local mobility (see
> > > RFC 3753).
> > > 
> > > > Mobility within a campus is most often handled by layer 2 
> > > protocols, 
> > > > such as dynamic VLANs, that require no change to the node's 
> > > > topological location (IP prefixes or addresses).  Mobility 
> > > across the 
> > > > Internet does require some change to the topological 
> > > information, at 
> > > > least at some level, and is handled by MIP (v4 or v6).
> > > 
> > > You can move into a campus and do a L3 handoff between 2 subnets
> > > (i.e. L3). If the service provider is different, this is "global 
> > > mobility", if
> > > it's the same provider (2 WLAN, with no L2-bridging) this 
> is "local
> > > mobility".
> > > 
> > > L3 mobility can be handled my MIP4/6 if it's a host (or 
> using other
> > > proprietary management protocols, e.g. LIN6), or by NEMO Basic
> > > Support if it's a router, or other standardized/not standardized
> > > mechanisms.
> > >  
> > > > Renumbering:  Changing a node's topological location within the 
> > > > Internet.  A node that previously had one topological 
> location (IP
> > > >  address prefix) is reconfigured to have a new topological
> > > >  location.
> > > 
> > > Renumbering to me means adversiting a new prefix, with the result
> > > that the node would have a new IP address. So, I wouldn't say
> > > "changing the topological location" as the word "changing" bring a
> > > sense of  "proactive
> > > behavior" of the node, whereas it is indeed "reactive behavior".
> > > 
> > > During the process of renumbering, the nodes may be 
> > > "multihomed" during
> > > a transient period of time.
> > > 
> > > > Multihoming:  Allowing a node that has more than one 
> topological 
> > > > location within     the Internet to use its redundant paths for 
> > > > efficient or reliable Internet connectivity. Note that 
> multihoming
> > > >  _does not_ involve changing the node's point(s) of 
> > > attachment to the 
> > > > Internet and/or changing the node's topological locations 
> > > within the 
> > > > Internet; the node has more than one topological location on an 
> > > > ongoing basis.
> > > 
> > > Agree on this.
> > >  
> > > > Now, clearly the above definitions are related, particularly if
> > > > you  view renumbering and mobility as the process of 
> adding a new 
> > > > topological location and removing an old one (perhaps very 
> > > quickly in 
> > > > some situations).  However, there is a very important 
> difference:
> > > > 
> > > > *** In shim6, two nodes can exchange their full set of 
> topological
> > > >  locations at the beginning of the session and they are not
> > > >  expected 
> > > > to change during the lifetime of the session. ***
> > > > 
> > > > The shim6 mechanism might be a useful tool to soften 
> the blow of 
> > > > renumbering.  A new address prefix (topological 
> location) could be
> > > >  added, and hosts could be multihomed for a while during which 
> > > > longer-lived connections and associations could be 
> migrated to the
> > > >  new topological location (manually, or using some other
> > > >  solution). 
> > > > Then, the old topological information could be deprecated 
> > > and removed 
> > > > on a schedule that allows the completion of shorter lived 
> > > > connections.  So, shim6 is not a renumbering solution, but it
> > > > might  be usefully applied to the problem of renumbering.
> > > > 
> > > > It is not easy to see how shim6 (as defined) could apply 
> > > directly to 
> > > > mobility, as described above.  Using shim6 as a 
> mobility mechanism
> > > >  would (at minimum) involve adding new topological 
> information in 
> > > > mid-session and might involve adding new topological 
> > > information at a 
> > > > time when the node is unreachable using the old topological 
> > > > information.  This creates a universe of protocol issues 
> > > and security 
> > > > concerns that are not present in the simpler multihoming 
> > > case, and I 
> > > > would prefer that we don't try to solve this problem 
> right now as 
> > > > part of the shim6 solution.
> > > 
> > > I agree that it's not straight forward to see shim6 applying for
> > > mobility, but I think that what Avri was trying to say is 
> > > that it would
> > > be a shame if such an important change wouldn't at the same time
> > > bring an answer to the mobility issue (particularly given the fact
> > > that an important proportion of nodes would be mobile).
> > > 
> > > So, playing an evil game, mobility-concerned people may 
> wonder what
> > > is the benefit of such an architectural changes if the mobility
> > > problem remain unchanged ? (does it worth the effort ?).
> > > 
> > > Thierry.
> > > 
> > > 
> > > > Personally, I respect all of the work that has gone into the
> > > > Mobile  IP solutions, and I think that we would be 
> underestimating
> > > > the  difficulty and subtlety of that problem space if we assume
> > > > that it  can be solved by a simple variant of the shim6 
> approach. 
> > > > I 
> > > do think 
> > > > it is important for shim6 to co-exist peacefully with MIPv4 and
> > > > v6,  and I think that is sufficient, at least for our 
> first step.
> > > 
> > > 
> 
> 

Delivery-date: Thu, 17 Mar 2005 04:42:07 +0000
Date: Thu, 17 Mar 2005 13:46:20 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

> I will take it further.  Margaret is correct and I will be stronger
> and replace the word tangential with orthogonal.  Mobility and
> Multihoming are completely two separate technology efforts and
> functions related to building a multihome archictecture, a network
> operations model for an enterprise, or a shim solution within an IP
> stack. 

The motiviations behind mobility and multihoming are distinct (i.e. the
intention is orthogonal) but the solutions MAY be similar / could
apply to one another / could be the same (i.e. the result may not be
orthogonal).

> Another example is Mobile IPv6 et al (multiple working groups
> on mobility) is completely orthogonal to MANETs problem of routing or
> autoconfiguratin on the link.
> 
> 
> In my opinion I have seen some views expressed to try to integrate
> Mobility issues-problems-opportunities into the work of multihoming

I'm not sure it's the intention. I would better take this as a "concern"
(deploying an architectural change which doesn't solve the mobility
problem is at best a loss of opportunity and at worse a lack of
planning) . I personaly have no intention to integrate mobility issues
or problems into the Shim6 WG as long as the output are **experimental
RFCs**.  However, it may be useful if a twin IRTF is set up to
investigate the relation between mobility and multihoming using a shim
(or compatible with a shim) so that, in the end, we can output - in a
few years and in other WGs - RFCs in the standard track category which
bring an answer to both mobility and multihoming. 

> and I believe to circumvent the IETF direction in the respective
> mobility WGs, as end-run as opposed to going to those IETF WGs and
> defending their need technically with that IETF center of expertise.

The existing mobiliy WGs are not chartered to discuss this.

Thierry.
 
> /jim 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Thierry Ernst
> > Sent: Wednesday, March 16, 2005 10:35 PM
> > To: [email-masked]
> > Subject: Re: how mobile do we want to be
> > 
> > 
> > I'm not sure that Margaret definitions are right. See below.
> > 
> > On Mon, 14 Mar 2005 14:43:31 -0500
> > Margaret Wasserman <[email-masked]> wrote: 
> > > Personally, I consider the subjects of mobility and renumbering to
> > >  both be somewhat tangential to the subject of multihoming. 
> > > Certainly, they are all related in some ways, but they are not the
> > >  same problem and may not have the same solution.
> > 
> > There are diffrent topics when we do think about the motivations /
> > needs, but that may be similar when thinking about mobility.
> > Mobility solutions could serve as a means to renumber/multihome and
> > multihoming solutions could serve as a means to solve mobility ...
> > So, it's not orthogonal as it depends from which perspective you
> > look at  the picture.
> > 
> > > To my way of thinking, the following definitions apply:
> > > 
> > > Mobility:  Changing a node's point of attachment to the Internet 
> > > without losing L3 sessions. Depending on the mechanism employed, 
> > > mobility may or may not involve changing the topological 
> > location of 
> > > the node within the Internet (i.e. the IP address prefix of 
> > the node).
> > 
> > "IP-layer mobility" means changing the L3 point of attachment and
> > "mobility support" is the abilitiy to do this without losing the
> > sessions. Such mobility necessarily means that the 
> > topological location
> > of the node would be changed (if not, I don't understand the 
> > scenario),
> > and, in such a case, that the IP address would be changed (an 
> > interface
> > must obtain an address on the link it is attached to, right 
> > ?). However,
> > depending on the solution to support this, upper layers may 
> > not see the
> > change of IP address (e.g. mobility).
> > 
> > > There are two subtypes of mobility:  mobility within a 
> > campus (under 
> > > a single administrative domain) and mobility across the Internet. 
> > 
> > This is called Macro/Global mobility and Micro/Local mobility (see
> > RFC 3753).
> > 
> > > Mobility within a campus is most often handled by layer 2 
> > protocols, 
> > > such as dynamic VLANs, that require no change to the node's 
> > > topological location (IP prefixes or addresses).  Mobility 
> > across the 
> > > Internet does require some change to the topological 
> > information, at 
> > > least at some level, and is handled by MIP (v4 or v6).
> > 
> > You can move into a campus and do a L3 handoff between 2 subnets
> > (i.e. L3). If the service provider is different, this is "global 
> > mobility", if
> > it's the same provider (2 WLAN, with no L2-bridging) this is "local
> > mobility".
> > 
> > L3 mobility can be handled my MIP4/6 if it's a host (or using other
> > proprietary management protocols, e.g. LIN6), or by NEMO Basic
> > Support if it's a router, or other standardized/not standardized
> > mechanisms.
> >  
> > > Renumbering:  Changing a node's topological location within the 
> > > Internet.  A node that previously had one topological location (IP
> > >  address prefix) is reconfigured to have a new topological
> > >  location.
> > 
> > Renumbering to me means adversiting a new prefix, with the result
> > that the node would have a new IP address. So, I wouldn't say
> > "changing the topological location" as the word "changing" bring a
> > sense of  "proactive
> > behavior" of the node, whereas it is indeed "reactive behavior".
> > 
> > During the process of renumbering, the nodes may be 
> > "multihomed" during
> > a transient period of time.
> > 
> > > Multihoming:  Allowing a node that has more than one topological 
> > > location within     the Internet to use its redundant paths for 
> > > efficient or reliable Internet connectivity. Note that multihoming
> > >  _does not_ involve changing the node's point(s) of 
> > attachment to the 
> > > Internet and/or changing the node's topological locations 
> > within the 
> > > Internet; the node has more than one topological location on an 
> > > ongoing basis.
> > 
> > Agree on this.
> >  
> > > Now, clearly the above definitions are related, particularly if
> > > you  view renumbering and mobility as the process of adding a new 
> > > topological location and removing an old one (perhaps very 
> > quickly in 
> > > some situations).  However, there is a very important difference:
> > > 
> > > *** In shim6, two nodes can exchange their full set of topological
> > >  locations at the beginning of the session and they are not
> > >  expected 
> > > to change during the lifetime of the session. ***
> > > 
> > > The shim6 mechanism might be a useful tool to soften the blow of 
> > > renumbering.  A new address prefix (topological location) could be
> > >  added, and hosts could be multihomed for a while during which 
> > > longer-lived connections and associations could be migrated to the
> > >  new topological location (manually, or using some other
> > >  solution). 
> > > Then, the old topological information could be deprecated 
> > and removed 
> > > on a schedule that allows the completion of shorter lived 
> > > connections.  So, shim6 is not a renumbering solution, but it
> > > might  be usefully applied to the problem of renumbering.
> > > 
> > > It is not easy to see how shim6 (as defined) could apply 
> > directly to 
> > > mobility, as described above.  Using shim6 as a mobility mechanism
> > >  would (at minimum) involve adding new topological information in 
> > > mid-session and might involve adding new topological 
> > information at a 
> > > time when the node is unreachable using the old topological 
> > > information.  This creates a universe of protocol issues 
> > and security 
> > > concerns that are not present in the simpler multihoming 
> > case, and I 
> > > would prefer that we don't try to solve this problem right now as 
> > > part of the shim6 solution.
> > 
> > I agree that it's not straight forward to see shim6 applying for
> > mobility, but I think that what Avri was trying to say is 
> > that it would
> > be a shame if such an important change wouldn't at the same time
> > bring an answer to the mobility issue (particularly given the fact
> > that an important proportion of nodes would be mobile).
> > 
> > So, playing an evil game, mobility-concerned people may wonder what
> > is the benefit of such an architectural changes if the mobility
> > problem remain unchanged ? (does it worth the effort ?).
> > 
> > Thierry.
> > 
> > 
> > > Personally, I respect all of the work that has gone into the
> > > Mobile  IP solutions, and I think that we would be underestimating
> > > the  difficulty and subtlety of that problem space if we assume
> > > that it  can be solved by a simple variant of the shim6 approach. 
> > > I 
> > do think 
> > > it is important for shim6 to co-exist peacefully with MIPv4 and
> > > v6,  and I think that is sufficient, at least for our first step.
> > 
> > 

Delivery-date: Thu, 17 Mar 2005 04:01:45 +0000
Content-class: urn:content-classes:message
Subject: RE: how mobile do we want to be
Date: Wed, 16 Mar 2005 23:01:26 -0500
From: "Bound, Jim" <[email-masked]>
To: "Thierry Ernst" <[email-masked]>, <[email-masked]>

I will take it further.  Margaret is correct and I will be stronger and
replace the word tangential with orthogonal.  Mobility and Multihoming
are completely two separate technology efforts and functions related to
building a multihome archictecture, a network operations model for an
enterprise, or a shim solution within an IP stack.  Another example is
Mobile IPv6 et al (multiple working groups on mobility) is completely
orthogonal to MANETs problem of routing or autoconfiguratin on the link.

In my opinion I have seen some views expressed to try to integrate
Mobility issues-problems-opportunities into the work of multihoming and
I believe to circumvent the IETF direction in the respective mobility
WGs, as end-run as opposed to going to those IETF WGs and defending
their need technically with that IETF center of expertise.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thierry Ernst
> Sent: Wednesday, March 16, 2005 10:35 PM
> To: [email-masked]
> Subject: Re: how mobile do we want to be
> 
> 
> I'm not sure that Margaret definitions are right. See below.
> 
> On Mon, 14 Mar 2005 14:43:31 -0500
> Margaret Wasserman <[email-masked]> wrote: 
> > Personally, I consider the subjects of mobility and renumbering to 
> > both be somewhat tangential to the subject of multihoming. 
> > Certainly, they are all related in some ways, but they are not the 
> > same problem and may not have the same solution.
> 
> There are diffrent topics when we do think about the motivations /
> needs, but that may be similar when thinking about mobility. Mobility
> solutions could serve as a means to renumber/multihome and multihoming
> solutions could serve as a means to solve mobility ... So, it's not
> orthogonal as it depends from which perspective you look at 
> the picture.
> 
> > To my way of thinking, the following definitions apply:
> > 
> > Mobility:  Changing a node's point of attachment to the Internet 
> > without losing L3 sessions. Depending on the mechanism employed, 
> > mobility may or may not involve changing the topological 
> location of 
> > the node within the Internet (i.e. the IP address prefix of 
> the node).
> 
> "IP-layer mobility" means changing the L3 point of attachment and
> "mobility support" is the abilitiy to do this without losing the
> sessions. Such mobility necessarily means that the 
> topological location
> of the node would be changed (if not, I don't understand the 
> scenario),
> and, in such a case, that the IP address would be changed (an 
> interface
> must obtain an address on the link it is attached to, right 
> ?). However,
> depending on the solution to support this, upper layers may 
> not see the
> change of IP address (e.g. mobility).
> 
> > There are two subtypes of mobility:  mobility within a 
> campus (under 
> > a single administrative domain) and mobility across the Internet. 
> 
> This is called Macro/Global mobility and Micro/Local mobility (see RFC
> 3753).
> 
> > Mobility within a campus is most often handled by layer 2 
> protocols, 
> > such as dynamic VLANs, that require no change to the node's 
> > topological location (IP prefixes or addresses).  Mobility 
> across the 
> > Internet does require some change to the topological 
> information, at 
> > least at some level, and is handled by MIP (v4 or v6).
> 
> You can move into a campus and do a L3 handoff between 2 subnets (i.e.
> L3). If the service provider is different, this is "global 
> mobility", if
> it's the same provider (2 WLAN, with no L2-bridging) this is "local
> mobility".
> 
> L3 mobility can be handled my MIP4/6 if it's a host (or using other
> proprietary management protocols, e.g. LIN6), or by NEMO Basic Support
> if it's a router, or other standardized/not standardized mechanisms.
>  
> > Renumbering:  Changing a node's topological location within the 
> > Internet.  A node that previously had one topological location (IP 
> > address prefix) is reconfigured to have a new topological location.
> 
> Renumbering to me means adversiting a new prefix, with the result that
> the node would have a new IP address. So, I wouldn't say "changing the
> topological location" as the word "changing" bring a sense of 
> "proactive
> behavior" of the node, whereas it is indeed "reactive behavior".
> 
> During the process of renumbering, the nodes may be 
> "multihomed" during
> a transient period of time.
> 
> > Multihoming:  Allowing a node that has more than one topological 
> > location within     the Internet to use its redundant paths for 
> > efficient or reliable Internet connectivity. Note that multihoming 
> > _does not_ involve changing the node's point(s) of 
> attachment to the 
> > Internet and/or changing the node's topological locations 
> within the 
> > Internet; the node has more than one topological location on an 
> > ongoing basis.
> 
> Agree on this.
>  
> > Now, clearly the above definitions are related, particularly if you 
> > view renumbering and mobility as the process of adding a new 
> > topological location and removing an old one (perhaps very 
> quickly in 
> > some situations).  However, there is a very important difference:
> > 
> > *** In shim6, two nodes can exchange their full set of topological 
> > locations at the beginning of the session and they are not expected 
> > to change during the lifetime of the session. ***
> > 
> > The shim6 mechanism might be a useful tool to soften the blow of 
> > renumbering.  A new address prefix (topological location) could be 
> > added, and hosts could be multihomed for a while during which 
> > longer-lived connections and associations could be migrated to the 
> > new topological location (manually, or using some other solution). 
> > Then, the old topological information could be deprecated 
> and removed 
> > on a schedule that allows the completion of shorter lived 
> > connections.  So, shim6 is not a renumbering solution, but it might 
> > be usefully applied to the problem of renumbering.
> > 
> > It is not easy to see how shim6 (as defined) could apply 
> directly to 
> > mobility, as described above.  Using shim6 as a mobility mechanism 
> > would (at minimum) involve adding new topological information in 
> > mid-session and might involve adding new topological 
> information at a 
> > time when the node is unreachable using the old topological 
> > information.  This creates a universe of protocol issues 
> and security 
> > concerns that are not present in the simpler multihoming 
> case, and I 
> > would prefer that we don't try to solve this problem right now as 
> > part of the shim6 solution.
> 
> I agree that it's not straight forward to see shim6 applying for
> mobility, but I think that what Avri was trying to say is 
> that it would
> be a shame if such an important change wouldn't at the same time bring
> an answer to the mobility issue (particularly given the fact that an
> important proportion of nodes would be mobile).
> 
> So, playing an evil game, mobility-concerned people may wonder what is
> the benefit of such an architectural changes if the mobility problem
> remain unchanged ? (does it worth the effort ?).
> 
> Thierry.
> 
> 
> > Personally, I respect all of the work that has gone into the Mobile 
> > IP solutions, and I think that we would be underestimating the 
> > difficulty and subtlety of that problem space if we assume that it 
> > can be solved by a simple variant of the shim6 approach.  I 
> do think 
> > it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
> > and I think that is sufficient, at least for our first step.
> 
> 

Delivery-date: Thu, 17 Mar 2005 03:30:58 +0000
Date: Thu, 17 Mar 2005 12:35:15 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

I'm not sure that Margaret definitions are right. See below.

On Mon, 14 Mar 2005 14:43:31 -0500
Margaret Wasserman <[email-masked]> wrote: 
> Personally, I consider the subjects of mobility and renumbering to 
> both be somewhat tangential to the subject of multihoming. 
> Certainly, they are all related in some ways, but they are not the 
> same problem and may not have the same solution.

There are diffrent topics when we do think about the motivations /
needs, but that may be similar when thinking about mobility. Mobility
solutions could serve as a means to renumber/multihome and multihoming
solutions could serve as a means to solve mobility ... So, it's not
orthogonal as it depends from which perspective you look at the picture.

> To my way of thinking, the following definitions apply:
> 
> Mobility:  Changing a node's point of attachment to the Internet 
> without losing L3 sessions. Depending on the mechanism employed, 
> mobility may or may not involve changing the topological location of 
> the node within the Internet (i.e. the IP address prefix of the node).

"IP-layer mobility" means changing the L3 point of attachment and
"mobility support" is the abilitiy to do this without losing the
sessions. Such mobility necessarily means that the topological location
of the node would be changed (if not, I don't understand the scenario),
and, in such a case, that the IP address would be changed (an interface
must obtain an address on the link it is attached to, right ?). However,
depending on the solution to support this, upper layers may not see the
change of IP address (e.g. mobility).

> There are two subtypes of mobility:  mobility within a campus (under 
> a single administrative domain) and mobility across the Internet. 

This is called Macro/Global mobility and Micro/Local mobility (see RFC
3753).

> Mobility within a campus is most often handled by layer 2 protocols, 
> such as dynamic VLANs, that require no change to the node's 
> topological location (IP prefixes or addresses).  Mobility across the 
> Internet does require some change to the topological information, at 
> least at some level, and is handled by MIP (v4 or v6).

You can move into a campus and do a L3 handoff between 2 subnets (i.e.
L3). If the service provider is different, this is "global mobility", if
it's the same provider (2 WLAN, with no L2-bridging) this is "local
mobility".

L3 mobility can be handled my MIP4/6 if it's a host (or using other
proprietary management protocols, e.g. LIN6), or by NEMO Basic Support
if it's a router, or other standardized/not standardized mechanisms.
 
> Renumbering:  Changing a node's topological location within the 
> Internet.  A node that previously had one topological location (IP 
> address prefix) is reconfigured to have a new topological location.

Renumbering to me means adversiting a new prefix, with the result that
the node would have a new IP address. So, I wouldn't say "changing the
topological location" as the word "changing" bring a sense of "proactive
behavior" of the node, whereas it is indeed "reactive behavior".

During the process of renumbering, the nodes may be "multihomed" during
a transient period of time.

> Multihoming:  Allowing a node that has more than one topological 
> location within     the Internet to use its redundant paths for 
> efficient or reliable Internet connectivity. Note that multihoming 
> _does not_ involve changing the node's point(s) of attachment to the 
> Internet and/or changing the node's topological locations within the 
> Internet; the node has more than one topological location on an 
> ongoing basis.

Agree on this.
 
> Now, clearly the above definitions are related, particularly if you 
> view renumbering and mobility as the process of adding a new 
> topological location and removing an old one (perhaps very quickly in 
> some situations).  However, there is a very important difference:
> 
> *** In shim6, two nodes can exchange their full set of topological 
> locations at the beginning of the session and they are not expected 
> to change during the lifetime of the session. ***
> 
> The shim6 mechanism might be a useful tool to soften the blow of 
> renumbering.  A new address prefix (topological location) could be 
> added, and hosts could be multihomed for a while during which 
> longer-lived connections and associations could be migrated to the 
> new topological location (manually, or using some other solution). 
> Then, the old topological information could be deprecated and removed 
> on a schedule that allows the completion of shorter lived 
> connections.  So, shim6 is not a renumbering solution, but it might 
> be usefully applied to the problem of renumbering.
> 
> It is not easy to see how shim6 (as defined) could apply directly to 
> mobility, as described above.  Using shim6 as a mobility mechanism 
> would (at minimum) involve adding new topological information in 
> mid-session and might involve adding new topological information at a 
> time when the node is unreachable using the old topological 
> information.  This creates a universe of protocol issues and security 
> concerns that are not present in the simpler multihoming case, and I 
> would prefer that we don't try to solve this problem right now as 
> part of the shim6 solution.

I agree that it's not straight forward to see shim6 applying for
mobility, but I think that what Avri was trying to say is that it would
be a shame if such an important change wouldn't at the same time bring
an answer to the mobility issue (particularly given the fact that an
important proportion of nodes would be mobile).

So, playing an evil game, mobility-concerned people may wonder what is
the benefit of such an architectural changes if the mobility problem
remain unchanged ? (does it worth the effort ?).

Thierry.

> Personally, I respect all of the work that has gone into the Mobile 
> IP solutions, and I think that we would be underestimating the 
> difficulty and subtlety of that problem space if we assume that it 
> can be solved by a simple variant of the shim6 approach.  I do think 
> it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
> and I think that is sufficient, at least for our first step.

Delivery-date: Thu, 17 Mar 2005 02:54:02 +0000
Date: Wed, 16 Mar 2005 18:53:13 -0800
From: Erik Nordmark <[email-masked]>
To: Pasi Sarolahti <[email-masked]>
CC: ext Jeroen Massar <[email-masked]>, Kurtis Lindqvist <[email-masked]>, [email-masked], Leif Johansson <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, "Bound, Jim" <[email-masked]>
Subject: Re: shim - transport/app communication

Pasi Sarolahti wrote:

> I was not so concerned about the techniques of conversions between
> strings and address structures, but the semantic issues that might arise
> when the address the application sees might not anymore be the same as
> the address actually used in communication. I was wondering what would
> happen, for example, when these addresses are being advertised out in
> the network as a part of some application protocol.

Worst case is that you advertise a subset of the available addresses.
This does no harm compared to an application which doesn't use the shim, 
since such an application would fail when the IP addresses pair it is 
using for communication, fails.

> Another example, I guess that bind() with IP address should still select
> the interface used for the socket, right? 

That's not mandated by POSIX/TOG AFAIK; I think this is implementation 
dependent.

> In principle, if assuming
> ULIDs, the parameter address would represent the host, not the
> interface. So some of the socket API functions would seem a bit
> ambiguous to me.

IP addresses are not the ideal handle for referring to interfaces on a 
host. That's why the IPv6 socket API uses interface indicies to refer to 
interfaces.

    Erik

Delivery-date: Thu, 17 Mar 2005 02:51:43 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Wed, 16 Mar 2005 21:51:30 -0500
From: "Bound, Jim" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Kurtis Lindqvist" <[email-masked]>
Cc: "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>, "Leif Johansson" <[email-masked]>, <[email-masked]>

Erik, thanks.  If we are to do this really I agree with your mail below
technically.  The key is that the ULID is dereferenced to an address
whereever possible in the nodes stack and always on the wire and if ULID
must be passed over the wire it must be in some encaped dst option is
one suggestion.  Also how do I trust it on the wire?

/jim 

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, March 16, 2005 9:47 PM
> To: Kurtis Lindqvist
> Cc: Bound, Jim; Pasi Sarolahti; ext Iljitsch van Beijnum; 
> Leif Johansson; [email-masked]
> Subject: Re: shim - transport/app communication
> 
> Kurtis Lindqvist wrote:
> > 
> > On Tue, 15 Mar 2005, Bound, Jim wrote:
> > 
> >>>So I'm afraid that applications that want to take advantage of shim
> >>>might need to use a different address family, at least.
> >>
> >>That is a non starter and will never be supported.  Might 
> as well move
> >>them to SCTP.
> > 
> > 
> > I have a vague memory that this was brought up after Erik's 
> presentation
> > to the apps area open meeting in D.C and I from what I 
> remember Erik was
> > stressing that this was one of fundamentals that could not 
> be changed. But
> > I hope that Erik can refresh my memory.
> 
> My take is that the shim6 approach provides working referral for 
> existing applications, as long as the locator that was picked 
> as a ULID 
> is still reachable. Thus you want to update the applications and 
> application protocols to do one of
>   - use a FQDN for referrals (since the DNS lookup will 
> return multiple 
> addresses to try)
>   - pass a list of addresses in referrals (so that the peer has a 
> fallback when the first one doesn't work)
> 
> But it is perfectly safe to use the shim for all applications. If an 
> application doesn't use the shim things will fail when the selected 
> address pair fails (even without any referrals), so the shim makes 
> things strictly better.
> 
> Of course, there might be performance reasons to not rely on 
> the shim. 
> For instance a DNS query, with multiple NS records to try, 
> might as well 
> bypass the shim since it has a higher level failover which doesn't 
> require creating state in the shim.
> 
> > In general the shim6 would have to be as transparent to the 
> application
> > (API) as possible.
> 
> yep.
> 
>     Erik
> 

Delivery-date: Thu, 17 Mar 2005 02:48:31 +0000
Date: Wed, 16 Mar 2005 18:47:27 -0800
From: Erik Nordmark <[email-masked]>
To: Kurtis Lindqvist <[email-masked]>
CC: "Bound, Jim" <[email-masked]>, Pasi Sarolahti <[email-masked]>, ext Iljitsch van Beijnum <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
Subject: Re: shim - transport/app communication

Kurtis Lindqvist wrote:
> 
> On Tue, 15 Mar 2005, Bound, Jim wrote:
> 
>>>So I'm afraid that applications that want to take advantage of shim
>>>might need to use a different address family, at least.
>>
>>That is a non starter and will never be supported.  Might as well move
>>them to SCTP.
> 
> 
> I have a vague memory that this was brought up after Erik's presentation
> to the apps area open meeting in D.C and I from what I remember Erik was
> stressing that this was one of fundamentals that could not be changed. But
> I hope that Erik can refresh my memory.

My take is that the shim6 approach provides working referral for 
existing applications, as long as the locator that was picked as a ULID 
is still reachable. Thus you want to update the applications and 
application protocols to do one of
  - use a FQDN for referrals (since the DNS lookup will return multiple 
addresses to try)
  - pass a list of addresses in referrals (so that the peer has a 
fallback when the first one doesn't work)

But it is perfectly safe to use the shim for all applications. If an 
application doesn't use the shim things will fail when the selected 
address pair fails (even without any referrals), so the shim makes 
things strictly better.

Of course, there might be performance reasons to not rely on the shim. 
For instance a DNS query, with multiple NS records to try, might as well 
bypass the shim since it has a higher level failover which doesn't 
require creating state in the shim.

> In general the shim6 would have to be as transparent to the application
> (API) as possible.

yep.

    Erik

Delivery-date: Thu, 17 Mar 2005 02:37:59 +0000
Date: Wed, 16 Mar 2005 18:37:23 -0800
From: Vijay Devarapalli <[email-masked]>
To: Thierry Ernst <[email-masked]>
CC: [email-masked]
Subject: Re: how mobile do we want to be

Thierry,

I guess you asked the question because mobile networks are done
in the NEMO WG. MIP6 WG only does host mobility.

when Geoff said Mobile IPv6 working group, I am sure he meant
all MIP6 related WGs. :)

Vijay

Thierry Ernst wrote:
> On Tue, 15 Mar 2005 04:30:09 +1100
> Geoff Huston <[email-masked]> wrote:
> 
>>At 02:41 AM 15/03/2005, [email-masked] wrote:
>>
>>>I think the question is more a recognition that the network is now a 
>>>network in motion:
>>
>>I don't think this is a helpful characterization, nor does it apply to
>>the  overwhelming majority of the 160,000 prefixes we see in V4, or
>>the somewhat  lesser number of prefixes in IPv6.
>>
>>There is a Mobile IPv6 working group, and the place to consider the
>>various  aspects of mobility in IPv6 is within that working group. 
> 
> 
> Excuse me, if the point is to investigate network in motion, I fail to
> see why the MIP6 WG (and not Mobile IPv6 WG) would be a good place, and
> I also fail to see why concepts other than mobile IPv6 (with a home
> address and a care-of address)  would be investigated in that WG.
> 
> Thierry
> 
> 
> 
> 
> 
>>To re-noodle over 
>>their work in shim6 is not entirely a helpful direction here. Perhaps
>>a  more helpful starting point in terms of scoping this work is the 
>>architecture draft prepared in the nulti6 context 
>>(http://draft-ietf-multi6-architecture.potaroo.net) (and in the
>>context of  this area of locator switching and the concept of a
>>dynamically changing  locator pool perhaps section 6 is a good
>>starting point)
>>
>> >It is for these reasons that I am arguing so insistently that we
>> >must 
>>include systems and networks in motion (if we want to reserve the term
>> mobility for
>>  > MIP4/6 to avoid confusion) as part of the problem space shim6 must
>>  > take 
>>into account.
>>
>>This sounds like a charter discussion point to me- I'm not sure I
>>heard you  raise it in the BOF last week, although mobility was
>>mentioned a number of  times in the BOF.
> 
> 

Delivery-date: Thu, 17 Mar 2005 02:24:01 +0000
Date: Thu, 17 Mar 2005 11:28:06 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

On Tue, 15 Mar 2005 04:30:09 +1100
Geoff Huston <[email-masked]> wrote:
> At 02:41 AM 15/03/2005, [email-masked] wrote:
> >I think the question is more a recognition that the network is now a 
> >network in motion:
> 
> I don't think this is a helpful characterization, nor does it apply to
> the  overwhelming majority of the 160,000 prefixes we see in V4, or
> the somewhat  lesser number of prefixes in IPv6.
> 
> There is a Mobile IPv6 working group, and the place to consider the
> various  aspects of mobility in IPv6 is within that working group. 

Excuse me, if the point is to investigate network in motion, I fail to
see why the MIP6 WG (and not Mobile IPv6 WG) would be a good place, and
I also fail to see why concepts other than mobile IPv6 (with a home
address and a care-of address)  would be investigated in that WG.

Thierry

> To re-noodle over 
> their work in shim6 is not entirely a helpful direction here. Perhaps
> a  more helpful starting point in terms of scoping this work is the 
> architecture draft prepared in the nulti6 context 
> (http://draft-ietf-multi6-architecture.potaroo.net) (and in the
> context of  this area of locator switching and the concept of a
> dynamically changing  locator pool perhaps section 6 is a good
> starting point)
> 
>  >It is for these reasons that I am arguing so insistently that we
>  >must 
> include systems and networks in motion (if we want to reserve the term
>  mobility for
>   > MIP4/6 to avoid confusion) as part of the problem space shim6 must
>   > take 
> into account.
> 
> This sounds like a charter discussion point to me- I'm not sure I
> heard you  raise it in the BOF last week, although mobility was
> mentioned a number of  times in the BOF.

Delivery-date: Thu, 17 Mar 2005 02:24:00 +0000
Date: Thu, 17 Mar 2005 11:28:20 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: how mobile do we want to be
Organization: Keio University

Dear all,

I attended half the BOF, but couldn't stay until the end as I had to
take my flight, so, sorry if I raise issues which was discussed in the
BOF.

First, I agree with what Avri said during the BOF - that there is an
opportunity window and that we may be losing a good opportunity to solve
once for all the mobility problem if we don't investigate it further.

However, I'm not sure it should be the purpose of the Shim6 WG as my
understanding is that it would produce Experimental RFCs, so I would
find myself satisfied in this situation, provied mobility is
investigated at the IETF.

Iljitsch van Beijnum <[email-masked]> wrote:
> On 14-mrt-05, at 16:41, [email-masked] wrote:
> 
> > I think the question is more a recognition that the network is now a
> >  network in motion:  systems move and networks move.  And while it
> >  is 
> > true that some part so the network, doesn't move, or moves very 
> > slowly, an overwhelming amount of the edge is in motion. And I think
> >  it is important to realize that a large number of  sessions should 
> > remain viable despite this continuous motion.

> Could you provide some examples of applications where a 
> disconnect/reconnect is sufficiently problematic that MIPv6 or 
> something similar is warranted?
> 
> So far the only stuff I can think of is remote login and streaming 
> audio/video.

First, I've a question for Avri. What do you mean by "network in
motion", is this the mobile networks that we are supporting in the NEMO
WG, or something else ? (I would say yes, but since you didn't mention
NEMO, I cannot be sure).

If NEMO scenarios are in mind, I would second Avri in saying that a
significant part of the Internet nodes would be "mobile" (either that
change their point of attachment [i.e. mobile host or mobile routers] or
they are located in a network which "gateway" is mobile). 

Basically, MIP6 bring a solution to the former, and NEMO BS to the
latter (thought NEMO BS is not providing routing optimization). That's
not the point. The point is that if Shinm6 is looking into a solution
which would require a major architectural change, then, yes, it would
make sense that this major architectural change takes mobility
explicitly into consideration. Here, I do agree with Avri.

A conclusion might be that Shim6 is a little bit immature to be set up
at the IETF, whereas a IRFT WG on that (taking mobility into
consideration) might make more sense.

> > In other words I think the question is not, "how mobile do we want
> > to  be", but how mobile are we and how mobile will we be by the time
> > a  shim6 solution is implemented and widely deployed.
> 
> My prediction: not very. 99% of all traffic today is either sessions 
> that go away within seconds, or can be easily reestablished after a 
> forced disconnect. I don't see how the other 1% is going to take over 
> the world any time soon.

Hold on, if we only have 1% of mobile nodes today, it may be because the
Internet is not tuned for mobility, and that IPv6 is not yet deployed.
IPv6 is a change to deploy neew usages, and most of these new usages
will be mobile (see my comment about who is mobile ealier in my mail).
Every human will have a mobile phone, and possibly, many millions of
them will carry a PAN (ako NEMO). All cars will have an embedded network
(and that could be NEMO too). That's a few hundred millions cars. 

This will happen by the time the Shim6 solution is deployed (if it can
be deployed, which I'm not sure it would if mobility is not considered).

> > It is for these reasons that I am arguing so insistently that we
> > must  include systems and networks in motion (if we want to reserve
> > the term  mobility for MIP4/6 to avoid confusion) as part of the
> > problem space  shim6 must take into account.
> 
> I don't think this is a good idea. Let's focus on the basic shim 
> functionality, and when we have something useful there, we can sync up
>  with other efforts and see what we need to do to avoid duplication of
>    
> effort and to gain synergy.

Why this had to be done at the IETF ? (I'm just asking, not opposing,
and, in summary, my concern is that mobility should be investigated one
place or another if a Shim6 solution is ever expected to be deployed).

Thierry.

Delivery-date: Wed, 16 Mar 2005 23:22:38 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Thu, 17 Mar 2005 00:22:04 +0100
To: Pasi Sarolahti <[email-masked]>

On 16-mrt-05, at 12:44, Pasi Sarolahti wrote:

> I was wondering what would
> happen, for example, when these addresses are being advertised out in
> the network as a part of some application protocol.

This is one of the reasons why it's a good idea to have the addresses 
that are exposed to the application be addresses that are actually 
reachable (most of the time). This means that as long as there aren't 
any failures, referrals work just as good or bad as they work now. 
Obviously when the initially used address becomes unreachable, the shim 
will move the session to another set of addresses and now trying to 
contact the original address will probably not be problem free. But 
it's still better than what you get without the shim.

> Another example, I guess that bind() with IP address should still 
> select
> the interface used for the socket, right? In principle, if assuming
> ULIDs, the parameter address would represent the host, not the
> interface.

That's a very interesting change in viewpoint, which may or may not 
have important consequences. Note that we often give routers loopback 
interfaces with real addresses (not ::1) exactly because they need an 
address that remains reachable despite the status of any one interface.

Iljitsch

Delivery-date: Wed, 16 Mar 2005 16:17:34 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Wed, 16 Mar 2005 11:17:27 -0500
From: "Bound, Jim" <[email-masked]>
To: "Jeroen Massar" <[email-masked]>, "Pasi Sarolahti" <[email-masked]>
Cc: <[email-masked]>

this is exactly what we need to be drilling down on and I am still
concerned about net centric communications.

thx
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeroen Massar
> Sent: Wednesday, March 16, 2005 8:42 AM
> To: Pasi Sarolahti
> Cc: [email-masked]
> Subject: RE: shim - transport/app communication
> 
> [I trimmed the cc list btw]
> 
> On Wed, 2005-03-16 at 13:44 +0200, Pasi Sarolahti wrote:
> <SNIP>
> >>  But the minimal requirement we could
> >> set is "use a getaddrinfo() loop to cycle through all the 
> addresses",
> >> the ULID magic can be put in the getaddrinfo() function 
> which returns
> >> ULID's instead of the routing IP's.
> >
> >I was not so concerned about the techniques of conversions between
> >strings and address structures, but the semantic issues that 
> might arise
> >when the address the application sees might not anymore be 
> the same as
> >the address actually used in communication. I was wondering 
> what would
> >happen, for example, when these addresses are being advertised out in
> >the network as a part of some application protocol.
> 
> Applications will not know that the packets traveling on the Internet
> will actually have translated headers, just like they don't know that
> their packets go over Ethernet, over a PPPoE tunnel, ATM, IPv6 in IPv4
> in ATM or whatever magic there is. The ID's on both sides stay stable.
> 
> >Another example, I guess that bind() with IP address should 
> still select
> >the interface used for the socket, right? In principle, if assuming
> >ULIDs, the parameter address would represent the host, not the
> >interface. So some of the socket API functions would seem a bit
> >ambiguous to me.
> 
> ULID's could be given to a host based on a 'service' context just like
> you assign eg 2001:db8::80 to the webserver and 2001:db8::993 to the
> secure IMAP box. For the machine and for the applications it should be
> completely transparent and they should never notice at all 
> that there is
> anything happening to the packets as they are translated on 
> both sides.
> 
> 
> The biggest concerns I can currently come up with are:
>  - translation table size (128bits x 2 per entry, entry per site/host)
>    When talking to 100k hosts, is this feasible?
>  - how to fill the translation table and keep it up-to-date 
> in a secure
> manner.
> 
> Especially the second entry has to be worked out and is the boiling
> point. eg if you multihome a DNS server, it can't be used for 
> doing the
> resolving of the translation table (if we would go for DNS) and other
> nice problems, but these will be solved in time.
> The first entry is mostly a concern to small computers, eg 
> mobile phones
> but could be avoided by letting a gateway doing the 
> translation, eg per
> site. In a mobile phone context, this could mean that the IPv6 address
> is the phonenumber and the current ISP (connectivity supplier) you are
> connected to does the translation for you. Would need some 
> quick updates
> though, but should not hurt the apps nor the phone in anyway.
> 
> Greets,
>  Jeroen
> 
> 

Delivery-date: Wed, 16 Mar 2005 16:09:16 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Wed, 16 Mar 2005 11:08:46 -0500
From: "Bound, Jim" <[email-masked]>
To: "Pasi Sarolahti" <[email-masked]>, "ext Jeroen Massar" <[email-masked]>
Cc: "Kurtis Lindqvist" <[email-masked]>, <[email-masked]>, "Leif Johansson" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

You have valid concern for implementation.  I won't comment further till
I see a formal new shim mail list BOF not the current ones.  It also can
have ramifications that are significant to network subsystem
implementation protocol maps, structures, and address families but lets
see next draft to this list.  None of this should be exposed on the wire
to the network and how it is transfered and discovered is very
important.

/jim 

> -----Original Message-----
> From: Pasi Sarolahti [mailto:[email-masked]] 
> Sent: Wednesday, March 16, 2005 6:44 AM
> To: ext Jeroen Massar
> Cc: Kurtis Lindqvist; [email-masked]; Leif Johansson; Iljitsch 
> van Beijnum; Bound, Jim
> Subject: RE: shim - transport/app communication
> 
> On Wed, 2005-03-16 at 12:31, ext Jeroen Massar wrote:
> 
> > Actually, the only thing an application should depend on 
> here is that it
> > supports IPv6 addresses, though I have to note that shim6 should be
> > named 'shim', as this trick can also work for IPv4 and then 
> they would
> > not even need IPv6 for that matter.
> 
> Agree.
> 
> >  But the minimal requirement we could
> > set is "use a getaddrinfo() loop to cycle through all the 
> addresses",
> > the ULID magic can be put in the getaddrinfo() function 
> which returns
> > ULID's instead of the routing IP's.
> 
> I was not so concerned about the techniques of conversions between
> strings and address structures, but the semantic issues that 
> might arise
> when the address the application sees might not anymore be the same as
> the address actually used in communication. I was wondering what would
> happen, for example, when these addresses are being advertised out in
> the network as a part of some application protocol.
> 
> Another example, I guess that bind() with IP address should 
> still select
> the interface used for the socket, right? In principle, if assuming
> ULIDs, the parameter address would represent the host, not the
> interface. So some of the socket API functions would seem a bit
> ambiguous to me.
> 
> Maybe I'm misunderstanding something, and these are not really valid
> concerns. I hope I am :-)
> 
> - Pasi
> 
> 

Delivery-date: Wed, 16 Mar 2005 13:42:47 +0000
Subject: RE: shim - transport/app communication
From: Jeroen Massar <[email-masked]>
To: Pasi Sarolahti <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Wed, 16 Mar 2005 14:42:23 +0100

--=-zYUFXKm0yU5n12MWpYIT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

[I trimmed the cc list btw]

On Wed, 2005-03-16 at 13:44 +0200, Pasi Sarolahti wrote:
<SNIP>
>>  But the minimal requirement we could
>> set is "use a getaddrinfo() loop to cycle through all the addresses",
>> the ULID magic can be put in the getaddrinfo() function which returns
>> ULID's instead of the routing IP's.
>
>I was not so concerned about the techniques of conversions between
>strings and address structures, but the semantic issues that might arise
>when the address the application sees might not anymore be the same as
>the address actually used in communication. I was wondering what would
>happen, for example, when these addresses are being advertised out in
>the network as a part of some application protocol.

Applications will not know that the packets traveling on the Internet
will actually have translated headers, just like they don't know that
their packets go over Ethernet, over a PPPoE tunnel, ATM, IPv6 in IPv4
in ATM or whatever magic there is. The ID's on both sides stay stable.

>Another example, I guess that bind() with IP address should still select
>the interface used for the socket, right? In principle, if assuming
>ULIDs, the parameter address would represent the host, not the
>interface. So some of the socket API functions would seem a bit
>ambiguous to me.

ULID's could be given to a host based on a 'service' context just like
you assign eg 2001:db8::80 to the webserver and 2001:db8::993 to the
secure IMAP box. For the machine and for the applications it should be
completely transparent and they should never notice at all that there is
anything happening to the packets as they are translated on both sides.

The biggest concerns I can currently come up with are:
 - translation table size (128bits x 2 per entry, entry per site/host)
   When talking to 100k hosts, is this feasible?
 - how to fill the translation table and keep it up-to-date in a secure
manner.

Especially the second entry has to be worked out and is the boiling
point. eg if you multihome a DNS server, it can't be used for doing the
resolving of the translation table (if we would go for DNS) and other
nice problems, but these will be solved in time.
The first entry is mostly a concern to small computers, eg mobile phones
but could be avoided by letting a gateway doing the translation, eg per
site. In a mobile phone context, this could mean that the IPv6 address
is the phonenumber and the current ISP (connectivity supplier) you are
connected to does the translation for you. Would need some quick updates
though, but should not hurt the apps nor the phone in anyway.

Greets,
 Jeroen

--=-zYUFXKm0yU5n12MWpYIT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-zYUFXKm0yU5n12MWpYIT--

Delivery-date: Wed, 16 Mar 2005 11:45:26 +0000
Subject: RE: shim - transport/app communication
From: Pasi Sarolahti <[email-masked]>
To: ext Jeroen Massar <[email-masked]>
Cc: Kurtis Lindqvist <[email-masked]>, [email-masked], Leif Johansson <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, "Bound, Jim" <[email-masked]>
Organization: Nokia Research Center
Date: Wed, 16 Mar 2005 13:44:11 +0200

--=-H624JYxeECsdzKKtEApq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-03-16 at 12:31, ext Jeroen Massar wrote:

> Actually, the only thing an application should depend on here is that it
> supports IPv6 addresses, though I have to note that shim6 should be
> named 'shim', as this trick can also work for IPv4 and then they would
> not even need IPv6 for that matter.

Agree.

>  But the minimal requirement we could
> set is "use a getaddrinfo() loop to cycle through all the addresses",
> the ULID magic can be put in the getaddrinfo() function which returns
> ULID's instead of the routing IP's.

I was not so concerned about the techniques of conversions between
strings and address structures, but the semantic issues that might arise
when the address the application sees might not anymore be the same as
the address actually used in communication. I was wondering what would
happen, for example, when these addresses are being advertised out in
the network as a part of some application protocol.

Another example, I guess that bind() with IP address should still select
the interface used for the socket, right? In principle, if assuming
ULIDs, the parameter address would represent the host, not the
interface. So some of the socket API functions would seem a bit
ambiguous to me.

Maybe I'm misunderstanding something, and these are not really valid
concerns. I hope I am :-)

- Pasi

--=-H624JYxeECsdzKKtEApq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-H624JYxeECsdzKKtEApq--

Delivery-date: Wed, 16 Mar 2005 10:31:48 +0000
Subject: RE: shim - transport/app communication
From: Jeroen Massar <[email-masked]>
To: Kurtis Lindqvist <[email-masked]>
Cc: [email-masked], Leif Johansson <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Pasi Sarolahti <[email-masked]>, "Bound, Jim" <[email-masked]>
Organization: Unfix
Date: Wed, 16 Mar 2005 11:31:33 +0100

--=-he8R/h7b9JaL/towjsEI
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-03-16 at 12:04 +0200, Kurtis Lindqvist wrote:
>
>On Tue, 15 Mar 2005, Bound, Jim wrote:
>> > So I'm afraid that applications that want to take advantage of shim
>> > might need to use a different address family, at least.
>>
>> That is a non starter and will never be supported.  Might as well move
>> them to SCTP.

I agree with Jim ;)

Actually, the only thing an application should depend on here is that it
supports IPv6 addresses, though I have to note that shim6 should be
named 'shim', as this trick can also work for IPv4 and then they would
not even need IPv6 for that matter. But the minimal requirement we could
set is "use a getaddrinfo() loop to cycle through all the addresses",
the ULID magic can be put in the getaddrinfo() function which returns
ULID's instead of the routing IP's.

If the host doesn't have knowledge of ULID, thus it doesn't support
shim, then it will simply use the normal routing IP's. Another box,
further down the route, eg a gateway, can then take care of the
shimming.

>In general the shim6 would have to be as transparent to the application
>(API) as possible.

Ack. getaddrinfo()+inet_ntop()+inet_pton() is supposed to allow this and
if appwriters would use these they would not even have to know about
AFI's, only about the fact that they need a long enough buffer to store
some strings in ;)

Greets,
 Jeroen

--=-he8R/h7b9JaL/towjsEI
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBCOAsDKaooUjM+fCMRAkMXAJ4xMwMLcN1aO4Ynn28VMM0aOjYSzQCfbPPp
Y94Bim2n8Uu/hxujW0PqhLo¸IC
-----END PGP SIGNATURE-----

--=-he8R/h7b9JaL/towjsEI--

Delivery-date: Wed, 16 Mar 2005 10:05:10 +0000
Date: Wed, 16 Mar 2005 12:04:30 +0200 (EET)
From: Kurtis Lindqvist <[email-masked]>
To: "Bound, Jim" <[email-masked]>
Cc: Pasi Sarolahti <[email-masked]>, ext Iljitsch van Beijnum <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
Subject: RE: shim - transport/app communication

On Tue, 15 Mar 2005, Bound, Jim wrote:
> > So I'm afraid that applications that want to take advantage of shim
> > might need to use a different address family, at least.
>
> That is a non starter and will never be supported.  Might as well move
> them to SCTP.

I have a vague memory that this was brought up after Erik's presentation
to the apps area open meeting in D.C and I from what I remember Erik was
stressing that this was one of fundamentals that could not be changed. But
I hope that Erik can refresh my memory.

In general the shim6 would have to be as transparent to the application
(API) as possible.

- kurtis -

Delivery-date: Tue, 15 Mar 2005 21:29:28 +0000
Date: Tue, 15 Mar 2005 23:29:20 +0200 (EET)
From: Kurtis Lindqvist <[email-masked]>
To: "Bound, Jim" <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, [email-masked], shim6 <[email-masked]>
Subject: RE: fragmenting the discussion space

	Jim,

On Tue, 15 Mar 2005, Bound, Jim wrote:

> Agree but the devil is in the details as you know.  Getting shims
> deployed in Linux and BSD is one thing getting them deployed in products
> is a completely different manner and implementation analysis and effect
> will be mandatory for consideration.  I will be able to help on that
> front.  I still believe if SCTP was deployed problem is solved.

the problem is that that still assumes SCTP and only SCTP. And that again
requires deployment and updates.

- kurtis -

Delivery-date: Tue, 15 Mar 2005 21:02:45 +0000
Content-class: urn:content-classes:message
Subject: RE: shim - transport/app communication
Date: Tue, 15 Mar 2005 16:02:34 -0500
From: "Bound, Jim" <[email-masked]>
To: "Pasi Sarolahti" <[email-masked]>, "ext Iljitsch van Beijnum" <[email-masked]>
Cc: "Leif Johansson" <[email-masked]>, <[email-masked]>

> So I'm afraid that applications that want to take advantage of shim
> might need to use a different address family, at least.

That is a non starter and will never be supported.  Might as well move
them to SCTP.

/jim

Delivery-date: Tue, 15 Mar 2005 21:00:23 +0000
Content-class: urn:content-classes:message
Subject: RE: fragmenting the discussion space
Date: Tue, 15 Mar 2005 16:00:04 -0500
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6" <[email-masked]>

I recall all the mail.  It is just my view that a shim to support SCTP
with TCP is cheaper, less cost, and less work than a shim in my kernel
as one developer.  Lets not go there I agree. I will watch this shim
discussion technically.  I don't think it will happen in the market.

/jim 

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Tuesday, March 15, 2005 3:55 PM
> To: Bound, Jim
> Cc: shim6
> Subject: Re: fragmenting the discussion space
> 
> On 15-mrt-05, at 15:58, Bound, Jim wrote:
> 
> > I still believe if SCTP was deployed problem is solved.
> 
> Ok I'm going to shut up about the mobility stuff now, but I 
> have to say 
> something about SCTP...
> 
> Let's assume for a moment that SCTPs multihoming is good. (I seem to 
> remember that it has issues, but can't remember those off the 
> top of my 
> head.)
> 
> The trouble is that SCTP is as good as undeployable. First of 
> all, it's 
> incompatible with TCP, so hosts would have to know in advance whether 
> to set up an SCTP or a TCP session. Worse, the API is quite different 
> from TCP. There is some glue that makes SCTP look pretty 
> close to TCP, 
> but then you lose all the new features, so there is no point. 
> So moving 
> to SCTP means updating ALL applications, and update them in a 
> significant way.
> 
> We've been over all of this and more in multi6. The shim is the place 
> to be. I'll be happy to forward the past two years worth of messages 
> (some 3700) to anyone who wants to catch up...
> 
> 

Delivery-date: Tue, 15 Mar 2005 20:56:00 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: fragmenting the discussion space
Date: Tue, 15 Mar 2005 21:55:06 +0100
To: "Bound, Jim" <[email-masked]>

On 15-mrt-05, at 15:58, Bound, Jim wrote:

> I still believe if SCTP was deployed problem is solved.

Ok I'm going to shut up about the mobility stuff now, but I have to say 
something about SCTP...

Let's assume for a moment that SCTPs multihoming is good. (I seem to 
remember that it has issues, but can't remember those off the top of my 
head.)

The trouble is that SCTP is as good as undeployable. First of all, it's 
incompatible with TCP, so hosts would have to know in advance whether 
to set up an SCTP or a TCP session. Worse, the API is quite different 
from TCP. There is some glue that makes SCTP look pretty close to TCP, 
but then you lose all the new features, so there is no point. So moving 
to SCTP means updating ALL applications, and update them in a 
significant way.

We've been over all of this and more in multi6. The shim is the place 
to be. I'll be happy to forward the past two years worth of messages 
(some 3700) to anyone who wants to catch up...

Delivery-date: Tue, 15 Mar 2005 16:47:55 +0000
Subject: Re: shim - transport/app communication
From: Pasi Sarolahti <[email-masked]>
To: ext Iljitsch van Beijnum <[email-masked]>
Cc: Leif Johansson <[email-masked]>, [email-masked]
Organization: Nokia Research Center
Date: Tue, 15 Mar 2005 18:45:59 +0200

--=-IHkCLJdACoZBirZ9RL+z
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-03-15 at 03:01, ext Iljitsch van Beijnum wrote:

> > I believe that keeping applications shim-unaware is a worthy goal.
> 
> Some applications may want to inform the shim of their special needs. 
> But applications that don't have special needs shouldn't have to be 
> shim-aware, of course.

Completely hiding shim6 from applications might be problematic, even
though I agree that it would be a nice property. Applications should see
ULIDs, right? (Where ULID could be one of the locators). This would
change the semantics of those functions that handle addresses, such as
getsockname() or bind()? Even if using one of the IP addresses as ULID,
application gets an address that might end up to be different from the
IP address that is actually used in the communication later on. This
could break applications that have logic based on these addresses, such
as those that pass the addresses to other hosts as a part of the
application protocol message exchange.

So I'm afraid that applications that want to take advantage of shim
might need to use a different address family, at least.

- Pasi

--=-IHkCLJdACoZBirZ9RL+z
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-IHkCLJdACoZBirZ9RL+z--

Delivery-date: Tue, 15 Mar 2005 14:58:26 +0000
Content-class: urn:content-classes:message
Subject: RE: fragmenting the discussion space
Date: Tue, 15 Mar 2005 09:58:18 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>, "shim6" <[email-masked]>

Agree but the devil is in the details as you know.  Getting shims
deployed in Linux and BSD is one thing getting them deployed in products
is a completely different manner and implementation analysis and effect
will be mandatory for consideration.  I will be able to help on that
front.  I still believe if SCTP was deployed problem is solved.

/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, March 15, 2005 9:53 AM
> To: Bound, Jim
> Cc: [email-masked]; shim6
> Subject: Re: fragmenting the discussion space
> 
> I think I would assert that shim6 does *not* change
> any fundamentals of addressing or routing (in particular
> it doesn't create a genuine id/loc split and it doesn't
> change the route aggregation model). The same is true
> of SCTP, by the way. So this particular model for multihoming
> doesn't seem to be all that radical to me.
> 
>     Brian
> 
> Bound, Jim wrote:
> > Mobility is orthogonal to the solution for multihoming.
> > /jim 
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On 
> >>Behalf Of [email-masked]
> >>Sent: Tuesday, March 15, 2005 9:18 AM
> >>To: shim6
> >>Subject: Re: fragmenting the discussion space
> >>
> >>Hi,
> >>
> >>I can understand that excluding some of the related issues makes a 
> >>discussion easier.  But isn't one of the reasons we have fragmented 
> >>solutions and lack a coherent architecture due to the fact 
> >>that we have 
> >>not yet learned to discuss complex issues including all of 
> >>the related 
> >>threads?
> >>
> >>In many cases, ignoring the details to get a quick solution out is 
> >>reasonable.  In the case of changing the basic behavior of 
> IP and of 
> >>the addressing architecture, this seems to me to be unwise.
> >>
> >>a.
> >>
> >>
> >>On 15 mar 2005, at 08.58, Brian E Carpenter wrote:
> >>
> >>
> >>>This thread shows fairly clearly why the BOF co-chairs
> >>>excluded mobility: we wanted shim6 to focus on a concrete
> >>>solution space, not to re-open old debates that we finally
> >>>got past in multi6.
> >>>
> >>
> >>
> >>
> > 
> > 
> 
> 

Delivery-date: Tue, 15 Mar 2005 14:53:34 +0000
Date: Tue, 15 Mar 2005 15:53:24 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Bound, Jim" <[email-masked]>
CC: [email-masked], shim6 <[email-masked]>
Subject: Re: fragmenting the discussion space

I think I would assert that shim6 does *not* change
any fundamentals of addressing or routing (in particular
it doesn't create a genuine id/loc split and it doesn't
change the route aggregation model). The same is true
of SCTP, by the way. So this particular model for multihoming
doesn't seem to be all that radical to me.

    Brian

Bound, Jim wrote:
> Mobility is orthogonal to the solution for multihoming.
> /jim 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of [email-masked]
>>Sent: Tuesday, March 15, 2005 9:18 AM
>>To: shim6
>>Subject: Re: fragmenting the discussion space
>>
>>Hi,
>>
>>I can understand that excluding some of the related issues makes a 
>>discussion easier.  But isn't one of the reasons we have fragmented 
>>solutions and lack a coherent architecture due to the fact 
>>that we have 
>>not yet learned to discuss complex issues including all of 
>>the related 
>>threads?
>>
>>In many cases, ignoring the details to get a quick solution out is 
>>reasonable.  In the case of changing the basic behavior of IP and of 
>>the addressing architecture, this seems to me to be unwise.
>>
>>a.
>>
>>
>>On 15 mar 2005, at 08.58, Brian E Carpenter wrote:
>>
>>
>>>This thread shows fairly clearly why the BOF co-chairs
>>>excluded mobility: we wanted shim6 to focus on a concrete
>>>solution space, not to re-open old debates that we finally
>>>got past in multi6.
>>>
>>
>>
>>
> 
> 

Delivery-date: Tue, 15 Mar 2005 14:30:13 +0000
Content-class: urn:content-classes:message
Subject: RE: fragmenting the discussion space
Date: Tue, 15 Mar 2005 09:29:58 -0500
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>, "shim6" <[email-masked]>

Mobility is orthogonal to the solution for multihoming.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, March 15, 2005 9:18 AM
> To: shim6
> Subject: Re: fragmenting the discussion space
> 
> Hi,
> 
> I can understand that excluding some of the related issues makes a 
> discussion easier.  But isn't one of the reasons we have fragmented 
> solutions and lack a coherent architecture due to the fact 
> that we have 
> not yet learned to discuss complex issues including all of 
> the related 
> threads?
> 
> In many cases, ignoring the details to get a quick solution out is 
> reasonable.  In the case of changing the basic behavior of IP and of 
> the addressing architecture, this seems to me to be unwise.
> 
> a.
> 
> 
> On 15 mar 2005, at 08.58, Brian E Carpenter wrote:
> 
> > This thread shows fairly clearly why the BOF co-chairs
> > excluded mobility: we wanted shim6 to focus on a concrete
> > solution space, not to re-open old debates that we finally
> > got past in multi6.
> >
> 
> 
> 

Delivery-date: Tue, 15 Mar 2005 14:18:16 +0000
From: [email-masked]
Subject: Re: fragmenting the discussion space
Date: Tue, 15 Mar 2005 09:17:57 -0500
To: shim6 <[email-masked]>

Hi,

I can understand that excluding some of the related issues makes a 
discussion easier.  But isn't one of the reasons we have fragmented 
solutions and lack a coherent architecture due to the fact that we have 
not yet learned to discuss complex issues including all of the related 
threads?

In many cases, ignoring the details to get a quick solution out is 
reasonable.  In the case of changing the basic behavior of IP and of 
the addressing architecture, this seems to me to be unwise.

a.

On 15 mar 2005, at 08.58, Brian E Carpenter wrote:

> This thread shows fairly clearly why the BOF co-chairs
> excluded mobility: we wanted shim6 to focus on a concrete
> solution space, not to re-open old debates that we finally
> got past in multi6.
>

Delivery-date: Tue, 15 Mar 2005 14:15:17 +0000
Content-class: urn:content-classes:message
Subject: RE: fragmenting the discussion space
Date: Tue, 15 Mar 2005 09:15:01 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "shim6" <[email-masked]>

I strongly agree with this decision and sorry I could not make Friday
BOF I had to be at customers Friday in St. Louis so left Thurs night.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Tuesday, March 15, 2005 8:59 AM
> To: shim6
> Subject: fragmenting the discussion space
> 
> This thread shows fairly clearly why the BOF co-chairs
> excluded mobility: we wanted shim6 to focus on a concrete
> solution space, not to re-open old debates that we finally
> got past in multi6.
> 
>      Brian
> 
> Iljitsch van Beijnum wrote:
> > On 14-mrt-05, at 21:02, Dave Crocker wrote:
> > 
> >> It strikes me that mobility vs. multihoming is not benefiting from 
> >> similar abstraction efforts,
> > 
> > 
> > Mobility and multihoming require very different tradeoffs. Mobility 
> > needs to be able to add new addresses to existing communication 
> > sessions/associations, but it can suffer having a home agent. 
> > Multihoming absolutely can't depend on a home agent, but it doesn't 
> > really need to add new addresses to existing sessions/associations.
> > 
> > Now if you are about to suggest a mechanism that can add 
> new addresses 
> > but doesn't need a home agent, and is sufficiently 
> light-weight that it 
> > won't overload the support lines, batteries in mobile 
> devices or the 
> > user's willingness to wait for something to happen after 
> clicking, we'll 
> > be happy to listen.
> > 
> >> nevermind the likely artificial distinction between IPv4 
> and IPv6 on 
> >> this topic
> > 
> > 
> > We don't even have enough IPv4 addresses to give everyone 
> _one_ address, 
> > let alone two or more... IPv4 is is dead. If it turns out 
> we can dress 
> > up the corpse with a shim4 layer, fine. If not, no big loss.
> > 
> >> and nevermind the real-world transition difficulties 
> created by any 
> >> suggestion that NATs much change.
> > 
> > 
> > Did I mention that IPv4 was dead?
> > 
> >> Does it bother anyone that we are marching down a path 
> that our next 
> >> decade or longer will require support for at least:
> > 
> > 
> >> 1. IPv4 mobile
> > 
> > 
> > Huh?
> > 
> >> 2. IPv6 mobile
> > 
> > 
> > Ok, I'll buy this one but it would be nice if someone bothered to 
> > implement it first.
> > 
> >> 3. IPv6 multihoming
> > 
> > 
> > People are actually waiting for this one.
> > 
> >> 4. TCP multihoming
> > 
> > 
> > What are you talking about?
> > 
> >> 5. SCTP multihoming
> > 
> > 
> > Nice try, but it comes up short in many respects.
> > 
> >> I notice that my windows desktop has pretty awful performance with 
> >> anything less than 512MB of memory.
> > 
> > 
> >> It would be nice not to march the Internet stack down the path of 
> >> requiring that much for my mobile phone.
> > 
> > 
> > Exactly. So we have to be careful about requiring strong crypto for 
> > basic functionality such as multihoming.
> > 
> > 
> 
> 
> 

Delivery-date: Tue, 15 Mar 2005 13:59:34 +0000
Date: Tue, 15 Mar 2005 14:58:34 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: shim6 <[email-masked]>
Subject: fragmenting the discussion space

This thread shows fairly clearly why the BOF co-chairs
excluded mobility: we wanted shim6 to focus on a concrete
solution space, not to re-open old debates that we finally
got past in multi6.

     Brian

Iljitsch van Beijnum wrote:
> On 14-mrt-05, at 21:02, Dave Crocker wrote:
> 
>> It strikes me that mobility vs. multihoming is not benefiting from 
>> similar abstraction efforts,
> 
> 
> Mobility and multihoming require very different tradeoffs. Mobility 
> needs to be able to add new addresses to existing communication 
> sessions/associations, but it can suffer having a home agent. 
> Multihoming absolutely can't depend on a home agent, but it doesn't 
> really need to add new addresses to existing sessions/associations.
> 
> Now if you are about to suggest a mechanism that can add new addresses 
> but doesn't need a home agent, and is sufficiently light-weight that it 
> won't overload the support lines, batteries in mobile devices or the 
> user's willingness to wait for something to happen after clicking, we'll 
> be happy to listen.
> 
>> nevermind the likely artificial distinction between IPv4 and IPv6 on 
>> this topic
> 
> 
> We don't even have enough IPv4 addresses to give everyone _one_ address, 
> let alone two or more... IPv4 is is dead. If it turns out we can dress 
> up the corpse with a shim4 layer, fine. If not, no big loss.
> 
>> and nevermind the real-world transition difficulties created by any 
>> suggestion that NATs much change.
> 
> 
> Did I mention that IPv4 was dead?
> 
>> Does it bother anyone that we are marching down a path that our next 
>> decade or longer will require support for at least:
> 
> 
>> 1. IPv4 mobile
> 
> 
> Huh?
> 
>> 2. IPv6 mobile
> 
> 
> Ok, I'll buy this one but it would be nice if someone bothered to 
> implement it first.
> 
>> 3. IPv6 multihoming
> 
> 
> People are actually waiting for this one.
> 
>> 4. TCP multihoming
> 
> 
> What are you talking about?
> 
>> 5. SCTP multihoming
> 
> 
> Nice try, but it comes up short in many respects.
> 
>> I notice that my windows desktop has pretty awful performance with 
>> anything less than 512MB of memory.
> 
> 
>> It would be nice not to march the Internet stack down the path of 
>> requiring that much for my mobile phone.
> 
> 
> Exactly. So we have to be careful about requiring strong crypto for 
> basic functionality such as multihoming.
> 
> 

Delivery-date: Tue, 15 Mar 2005 09:35:56 +0000
Date: Tue, 15 Mar 2005 10:35:10 +0100
From: Leif Johansson <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: [email-masked]
Subject: Re: shim - transport/app communication

Iljitsch van Beijnum wrote:
> On 15-mrt-05, at 0:19, Leif Johansson wrote:
> 
>>> Shim-aware transports/applications could also emit periodic 
>>> keepalives when they're otherwise idle so the shim knows it shouldn't 
>>> remove state yet. (In fact many applications and/or TCP already do so.)
> 
> 
>> That is typically done as a hack to keep NAT-boxen from ditching you
>> right?
> 
> 
> No, I think it's done (at the tcp level) to flush out dead sessions. I 
> rather like being able to put my laptop to sleep overnight and find my 
> SSH sessions still alive, though.
> 

Perhaps we are getting off topic but are you sure that isn't ssh
doing the work for you? Ssh definitely has a configuration option for
keepalive.

	MVH leifj

Delivery-date: Tue, 15 Mar 2005 01:01:56 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim - transport/app communication
Date: Tue, 15 Mar 2005 02:01:32 +0100
To: Leif Johansson <[email-masked]>

On 15-mrt-05, at 0:19, Leif Johansson wrote:

>> Shim-aware transports/applications could also emit periodic 
>> keepalives when they're otherwise idle so the shim knows it shouldn't 
>> remove state yet. (In fact many applications and/or TCP already do 
>> so.)

> That is typically done as a hack to keep NAT-boxen from ditching you
> right?

No, I think it's done (at the tcp level) to flush out dead sessions. I 
rather like being able to put my laptop to sleep overnight and find my 
SSH sessions still alive, though.

> Some applications do that, others simply break.

Are you saying that NAT breaks certain applications? That surely can't 
be...

> I believe that keeping applications shim-unaware is a worthy goal.

Some applications may want to inform the shim of their special needs. 
But applications that don't have special needs shouldn't have to be 
shim-aware, of course.

Delivery-date: Mon, 14 Mar 2005 23:19:41 +0000
Date: Tue, 15 Mar 2005 00:19:20 +0100
From: Leif Johansson <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: [email-masked]
Subject: Re: shim - transport/app communication

> 
> Shim-aware transports/applications could also emit periodic keepalives 
> when they're otherwise idle so the shim knows it shouldn't remove state 
> yet. (In fact many applications and/or TCP already do so.)
> 

That is typically done as a hack to keep NAT-boxen from ditching you
right? Some applications do that, others simply break.

I believe that keeping applications shim-unaware is a worthy goal.

	Cheers Leif

Delivery-date: Mon, 14 Mar 2005 21:15:26 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: how mobile do we want to be
Date: Mon, 14 Mar 2005 22:15:09 +0100
To: [email-masked]

On 14-mrt-05, at 16:41, [email-masked] wrote:

> I think the question is more a recognition that the network is now a 
> network in motion:  systems move and networks move.  And while it is 
> true that some part so the network, doesn't move, or moves very 
> slowly, an overwhelming amount of the edge is in motion. And I think 
> it is important to realize that a large number of  sessions should 
> remain viable despite this continuous motion.

Could you provide some examples of applications where a 
disconnect/reconnect is sufficiently problematic that MIPv6 or 
something similar is warranted?

So far the only stuff I can think of is remote login and streaming 
audio/video.

> In other words I think the question is not, "how mobile do we want to 
> be", but how mobile are we and how mobile will we be by the time a 
> shim6 solution is implemented and widely deployed.

My prediction: not very. 99% of all traffic today is either sessions 
that go away within seconds, or can be easily reestablished after a 
forced disconnect. I don't see how the other 1% is going to take over 
the world any time soon.

> It is for these reasons that I am arguing so insistently that we must 
> include systems and networks in motion (if we want to reserve the term 
> mobility for MIP4/6 to avoid confusion) as part of the problem space 
> shim6 must take into account.

I don't think this is a good idea. Let's focus on the basic shim 
functionality, and when we have something useful there, we can sync up 
with other efforts and see what we need to do to avoid duplication of 
effort and to gain synergy.

Delivery-date: Mon, 14 Mar 2005 21:03:33 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: fragmenting the solution space
Date: Mon, 14 Mar 2005 22:03:07 +0100
To: Dave Crocker <[email-masked]>

On 14-mrt-05, at 21:02, Dave Crocker wrote:

> It strikes me that mobility vs. multihoming is not benefiting from 
> similar abstraction efforts,

Mobility and multihoming require very different tradeoffs. Mobility 
needs to be able to add new addresses to existing communication 
sessions/associations, but it can suffer having a home agent. 
Multihoming absolutely can't depend on a home agent, but it doesn't 
really need to add new addresses to existing sessions/associations.

Now if you are about to suggest a mechanism that can add new addresses 
but doesn't need a home agent, and is sufficiently light-weight that it 
won't overload the support lines, batteries in mobile devices or the 
user's willingness to wait for something to happen after clicking, 
we'll be happy to listen.

> nevermind the likely artificial distinction between IPv4 and IPv6 on 
> this topic

We don't even have enough IPv4 addresses to give everyone _one_ 
address, let alone two or more... IPv4 is is dead. If it turns out we 
can dress up the corpse with a shim4 layer, fine. If not, no big loss.

> and nevermind the real-world transition difficulties created by any 
> suggestion that NATs much change.

Did I mention that IPv4 was dead?

> Does it bother anyone that we are marching down a path that our next 
> decade or longer will require support for at least:

> 1. IPv4 mobile

Huh?

> 2. IPv6 mobile

Ok, I'll buy this one but it would be nice if someone bothered to 
implement it first.

> 3. IPv6 multihoming

People are actually waiting for this one.

> 4. TCP multihoming

What are you talking about?

> 5. SCTP multihoming

Nice try, but it comes up short in many respects.

> I notice that my windows desktop has pretty awful performance with 
> anything less than 512MB of memory.

> It would be nice not to march the Internet stack down the path of 
> requiring that much for my mobile phone.

Exactly. So we have to be careful about requiring strong crypto for 
basic functionality such as multihoming.

Delivery-date: Mon, 14 Mar 2005 20:02:52 +0000
From: Dave Crocker <[email-masked]>
To: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 14 Mar 2005 12:02:44 -0800
Subject: fragmenting the solution space

Folks,

As i recall being told, there was a great deal of debate about the way to add local area network support for TCP/IP.  After all, the characteristics of a LAN are far different from a WAN.  So, all sorts of optimizations are possible and appealing.

Instead of giving in to that urge, TCP and IP were kept uniform across the different environments.  The only concession to the LAN that showed up in IP, itself, was the ability to do direct exchanges, without requiring a router.

Oh.  That isn't really a LAN issue, is it?  It's an issue about direct-vs-mediated communication.  I guess someone looked for the abstraction that was relevant, rather than getting bogged down in the different details, creating divergent capabilities.  (And as usual ISO nicely provides examples of this mistake, in this case with TP[0-4].

It strikes me that mobility vs. multihoming is not benefiting from similar abstraction efforts, nevermind the likely artificial distinction between IPv4 and IPv6 on this topic and nevermind the real-world transition difficulties created by any suggestion that NATs much change.

Does it bother anyone that we are marching down a path that our next decade or longer will require support for at least:

1. IPv4 mobile
2. IPv6 mobile
3. IPv6 multihoming
4. TCP multihoming
5. SCTP multihoming
and so on?

I notice that my windows desktop has pretty awful performance with anything less than 512MB of memory.  

It would be nice not to march the Internet stack down the path of requiring that much for my mobile phone.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Mon, 14 Mar 2005 19:44:01 +0000
Date: Mon, 14 Mar 2005 14:43:31 -0500
To: [email-masked], Geoff Huston <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: [email-masked]

Hi Avri,

At 1:07 PM -0500 3/14/05, [email-masked] wrote:
>The point I raised there, was that it did not make sense to make the 
>kind of major surgery we are doing to the IP, the so called stem of 
>the hourglass, without also considering the implications and 
>opportunities for mobility.  During the years of Multi6, this was 
>out of scope.  As we are currently discussing a new charter, a 
>charter for a major change to IP, I think it is important to take 
>system motion, or non MIP mobility, into account.

Personally, I consider the subjects of mobility and renumbering to 
both be somewhat tangential to the subject of multihoming. 
Certainly, they are all related in some ways, but they are not the 
same problem and may not have the same solution.

To my way of thinking, the following definitions apply:

Mobility:  Changing a node's point of attachment to the Internet 
without losing L3 sessions. Depending on the mechanism employed, 
mobility may or may not involve changing the topological location of 
the node within the Internet (i.e. the IP address prefix of the node).

There are two subtypes of mobility:  mobility within a campus (under 
a single administrative domain) and mobility across the Internet. 
Mobility within a campus is most often handled by layer 2 protocols, 
such as dynamic VLANs, that require no change to the node's 
topological location (IP prefixes or addresses).  Mobility across the 
Internet does require some change to the topological information, at 
least at some level, and is handled by MIP (v4 or v6).

Renumbering:  Changing a node's topological location within the 
Internet.  A node that previously had one topological location (IP 
address prefix) is reconfigured to have a new topological location.

Multihoming:  Allowing a node that has more than one topological 
location within     the Internet to use its redundant paths for 
efficient or reliable Internet connectivity. Note that multihoming 
_does not_ involve changing the node's point(s) of attachment to the 
Internet and/or changing the node's topological locations within the 
Internet; the node has more than one topological location on an 
ongoing basis.

Now, clearly the above definitions are related, particularly if you 
view renumbering and mobility as the process of adding a new 
topological location and removing an old one (perhaps very quickly in 
some situations).  However, there is a very important difference:

*** In shim6, two nodes can exchange their full set of topological 
locations at the beginning of the session and they are not expected 
to change during the lifetime of the session. ***

The shim6 mechanism might be a useful tool to soften the blow of 
renumbering.  A new address prefix (topological location) could be 
added, and hosts could be multihomed for a while during which 
longer-lived connections and associations could be migrated to the 
new topological location (manually, or using some other solution). 
Then, the old topological information could be deprecated and removed 
on a schedule that allows the completion of shorter lived 
connections.  So, shim6 is not a renumbering solution, but it might 
be usefully applied to the problem of renumbering.

It is not easy to see how shim6 (as defined) could apply directly to 
mobility, as described above.  Using shim6 as a mobility mechanism 
would (at minimum) involve adding new topological information in 
mid-session and might involve adding new topological information at a 
time when the node is unreachable using the old topological 
information.  This creates a universe of protocol issues and security 
concerns that are not present in the simpler multihoming case, and I 
would prefer that we don't try to solve this problem right now as 
part of the shim6 solution.

Personally, I respect all of the work that has gone into the Mobile 
IP solutions, and I think that we would be underestimating the 
difficulty and subtlety of that problem space if we assume that it 
can be solved by a simple variant of the shim6 approach.  I do think 
it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
and I think that is sufficient, at least for our first step.

Margaret

Delivery-date: Mon, 14 Mar 2005 18:08:07 +0000
Cc: [email-masked]
From: [email-masked]
Subject: Re: how mobile do we want to be
Date: Mon, 14 Mar 2005 13:07:45 -0500
To: Geoff Huston <[email-masked]>

On 14 mar 2005, at 12.30, Geoff Huston wrote:

> This sounds like a charter discussion point to me- I'm not sure I 
> heard you raise it in the BOF last week, although mobility was 
> mentioned a number of times in the BOF.

Indeed, and I did raise it several times during the BoF.  Rather 
insistently I thought.  and with some support from others in the room, 
I thought.

The point I raised there, was that it did not make sense to make the 
kind of major surgery we are doing to the IP, the so called stem of the 
hourglass, without also considering the implications and opportunities 
for mobility.  During the years of Multi6, this was out of scope.  As 
we are currently discussing a new charter, a charter for a major change 
to IP, I think it is important to take system motion, or non MIP 
mobility, into account.

> I don't think this is a helpful characterization, nor does it apply to 
> the overwhelming majority of the 160,000 prefixes we see in V4, or the 
> somewhat lesser number of prefixes in IPv6.

At this point, if I understand the mechanisms of MIP properly, this 
sort of movement would not show up in the prefixes.

also when you look at the kind of mobility we expect with portable 
devices (though currently committed to a MIP6 framework) I think it is 
natural to assume that more of the end systems will be mobile as time 
goes on.

>
> There is a Mobile IPv6 working group, and the place to consider the 
> various aspects of mobility in IPv6 is within that working group.

I don't think so.  The Mobile IPv6 WG is dedicated to a specific 
solution to mobility.  The only solution that seems currently available 
without the separation of identifier and locator.  If, however, we 
change that major assumption (ie. that Locator = Identifier) there 
perhaps additional solution fall out of the split.  And while they have 
an interest in assuring that shim6 does not break their solution, I see 
no reason why the ability of shim6 to support network motion is in 
their charter.  I think they are a WG dedicated to a specific solution.

In this case the opportunity of a new means to support system motion 
needs to be explored.  We had years of exploring the multi6 solution 
space.  It seems to me that we should spend at least a little time 
exploring the possibility that shim6 would offer solutions on the 
system motion side as well.  This is the reason I think that
a. the system and network in motion aspect should not be out of charter
b. that at the very least a design team should be set up as part of the 
proposed WG, with a specific milestone, to explore the implications for 
systems and network in motion (ie. non MIP mobility).

> To re-noodle over their work in shim6 is not entirely a helpful 
> direction here.

As I argue above, this is not a re-noodling, but a different way to 
look at the network architecture.  I think it would be irresponsible 
for us to not do an analysis of the implications of such a major 
architectural change.

> Perhaps a more helpful starting point in terms of scoping this work is 
> the architecture draft prepared in the nulti6 context 
> (http://draft-ietf-multi6-architecture.potaroo.net) (and in the 
> context of this area of locator switching and the concept of a 
> dynamically changing locator pool perhaps section 6 is a good starting 
> point)

It is good as far as it goes and is a very informative document, but it 
does not explore non MIP mobility.  I beleive this needs to be explored 
as part of the chartering effort.

a.

Delivery-date: Mon, 14 Mar 2005 17:31:00 +0000
Date: Tue, 15 Mar 2005 04:30:09 +1100
To: [email-masked], Iljitsch van Beijnum <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: how mobile do we want to be
Cc: [email-masked]

At 02:41 AM 15/03/2005, [email-masked] wrote:
>I think the question is more a recognition that the network is now a 
>network in motion:

I don't think this is a helpful characterization, nor does it apply to the 
overwhelming majority of the 160,000 prefixes we see in V4, or the somewhat 
lesser number of prefixes in IPv6.

There is a Mobile IPv6 working group, and the place to consider the various 
aspects of mobility in IPv6 is within that working group. To re-noodle over 
their work in shim6 is not entirely a helpful direction here. Perhaps a 
more helpful starting point in terms of scoping this work is the 
architecture draft prepared in the nulti6 context 
(http://draft-ietf-multi6-architecture.potaroo.net) (and in the context of 
this area of locator switching and the concept of a dynamically changing 
locator pool perhaps section 6 is a good starting point)

 >It is for these reasons that I am arguing so insistently that we must 
include systems and networks in motion (if we want to reserve the term 
mobility for
  > MIP4/6 to avoid confusion) as part of the problem space shim6 must take 
into account.

This sounds like a charter discussion point to me- I'm not sure I heard you 
raise it in the BOF last week, although mobility was mentioned a number of 
times in the BOF.

regards,

   Geoff

Delivery-date: Mon, 14 Mar 2005 15:42:12 +0000
Cc: [email-masked]
From: [email-masked]
Subject: Re: how mobile do we want to be
Date: Mon, 14 Mar 2005 10:41:36 -0500
To: Iljitsch van Beijnum <[email-masked]>

I think the question is more a recognition that the network is now a 
network in motion:  systems move and networks move.  And while it is 
true that some part so the network, doesn't move, or moves very slowly, 
an overwhelming amount of the edge is in motion. And I think it is 
important to realize that a large number of  sessions should remain 
viable despite this continuous motion.

In other words I think the question is not, "how mobile do we want to 
be", but how mobile are we and how mobile will we be by the time a 
shim6 solution is implemented and widely deployed.

It is for these reasons that I am arguing so insistently that we must 
include systems and networks in motion (if we want to reserve the term 
mobility for MIP4/6 to avoid confusion) as part of the problem space 
shim6 must take into account.

a.

On 12 mar 2005, at 10.44, Iljitsch van Beijnum wrote:

> In the discussion in the BOF yesterday there were different viewpoints 
> on the relationship between mobility and multihoming in general and 
> shim6 in particular.
>
> Apparently, some people are equating renumbering with mobility. Now 
> obviously mobility mechanisms can be used to renumber without skipping 
> a beat, but that doesn't mean mobility and renumbering are the same 
> thing.
>
> I think the important difference is the timescale. In mobility, the 
> assumption is that TCP sessions and other state are longer-lived than 
> locator addresses. In site renumbering, I very much doubt that this is 
> the case. At the very least, we're talking about the order of days 
> here, and _very_ few sessions or associations last for days. So in 
> nearly all cases, site renumbering can be addressed with regular 
> stateless autoconfiguration address deprecation.
>
> Please don't forget: adding a new address in the middle of a session 
> is a security nightmare. The only way this can be done reasonably is 
> with the help of strong crypto (magic PKI dust) or a home agent that 
> is impervious to on-path nastiness such as sniffing and MitM. 
> Obviously, for a good number of applications strong crypto isn't a 
> problem as they already use it today. But mandating strong crypto for 
> *everything* is very problematic for reasons of performance, 
> configuration and robustness. (Let the person who never clicked 
> "accept" on an SSL warning cast the first stone here.)
>
> I think HBAs are a very good compromise between reasonable security 
> and usability. It would be a shame to throw this out the window just 
> so one or two applications are saved from reconnecting once in a blue 
> moon. It takes a lot of reconnects to waste the same amount of time 
> that it takes to obtain and install an X.509 certificate...
>
>
>

Delivery-date: Sat, 12 Mar 2005 15:52:59 +0000
To: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: shim - transport/app communication
Date: Sat, 12 Mar 2005 16:52:53 +0100

Hi,

I was thinking: would it be useful for applications and/or transport to 
communicate with the shim using extension headers / options in select 
packets?

This has the nice property that it works regardless of how/where the 
shim is implemented, and it doesn't need any complex layer-to-layer 
communication mechanisms.

Shim-aware transports/applications could also emit periodic keepalives 
when they're otherwise idle so the shim knows it shouldn't remove state 
yet. (In fact many applications and/or TCP already do so.)

Delivery-date: Sat, 12 Mar 2005 15:45:29 +0000
To: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: how mobile do we want to be
Date: Sat, 12 Mar 2005 16:44:58 +0100

In the discussion in the BOF yesterday there were different viewpoints 
on the relationship between mobility and multihoming in general and 
shim6 in particular.

Apparently, some people are equating renumbering with mobility. Now 
obviously mobility mechanisms can be used to renumber without skipping 
a beat, but that doesn't mean mobility and renumbering are the same 
thing.

I think the important difference is the timescale. In mobility, the 
assumption is that TCP sessions and other state are longer-lived than 
locator addresses. In site renumbering, I very much doubt that this is 
the case. At the very least, we're talking about the order of days 
here, and _very_ few sessions or associations last for days. So in 
nearly all cases, site renumbering can be addressed with regular 
stateless autoconfiguration address deprecation.

Please don't forget: adding a new address in the middle of a session is 
a security nightmare. The only way this can be done reasonably is with 
the help of strong crypto (magic PKI dust) or a home agent that is 
impervious to on-path nastiness such as sniffing and MitM. Obviously, 
for a good number of applications strong crypto isn't a problem as they 
already use it today. But mandating strong crypto for *everything* is 
very problematic for reasons of performance, configuration and 
robustness. (Let the person who never clicked "accept" on an SSL 
warning cast the first stone here.)

I think HBAs are a very good compromise between reasonable security and 
usability. It would be a shame to throw this out the window just so one 
or two applications are saved from reconnecting once in a blue moon. It 
takes a lot of reconnects to waste the same amount of time that it 
takes to obtain and install an X.509 certificate...

Delivery-date: Fri, 04 Mar 2005 05:11:11 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Scribe
Date: Fri, 4 Mar 2005 06:10:44 +0100

	

While we already have a volunteer jabber scribe, we are still missing a 
scribed for the minutes. If you would be willing to do this, please 
send an email to the chairs at

[email-masked]
[email-masked]

Brian + Kurtis

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQift2qarNKXTPFCVEQI+lgCguNbmpD44UakkRYoEuFJ6361lyEsAoPFF
JGk8W6IjfAom533vK8gIonVd
élW
-----END PGP SIGNATURE-----

Delivery-date: Thu, 03 Mar 2005 16:23:43 +0000
To: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-huston-l3shim-arch-00.txt
Date: Thu, 3 Mar 2005 17:23:17 +0100

Hi,
I guess that this draft will be completed later, but in any case here 
there are some comments about this initial version.

In section 2.  Summary of L3Shim
it is stated that:

          The Layer 3 shim operates as a per-host header address mapping
          function.  When the shim locator mapping function is activated
          for a remote endpoint packets passed from the IP endpoint
          sub-layer to the shim sub-layer have the packet's headers
          source and destination addresses rewritten with the currently
          selected locator pair.  Incoming packets passed from the IP
          Routing sub-layer undergo a similar lookup using the locator
          pair.

Incoming packets probably will need to use a context tag in order to 
properly do the demultiplexing. Perhaps it would be good to mention it 
here.

later on in the same section it is stated that:

          Assuming that the initial choice of a ULID corresponds to a
          viable network path, the initial state of the L3Shim is a null
          mapping, as the ULID is also a viable locator.  The use of
          alternate locators by the L3Shim is a triggered response, based
          on a network path unreachability signal.

I guess that between these two states there is an intermediate step 
that is the creation of the context. such event is not triggered by the 
outage, but probably needs to be performed earlier. Moreover, the 
exchange of alternative locators needs to be done before the outage, in 
order to be able to recover from any type of outage. So i would suggest 
to mention something about the context state creation between the two 
sentences above.

In section  4.  Functional Decomposition subsection 4.1  Establishing 
Session State it is stated that:

             Does the identity protocol element need to create a mapping
             from the upper level protocol's local and remote identity
             tokens into an identity token that identifies the session?

W.r.t. this first question, i think that the context tag for 
identifying which packets need to be demultiplexed is as it name states 
a context identifier which imho is similar to a session identifier. So 
i guess that a session identifier is needed sometimes i.e. when al 
alternative locator is used.

             If so, then is this translation performed before or after
             the initial session packet exchange handshake?

I am not sure i understand this question as it is stated... what is the 
initial session packet exchange handshake? is this the data packet 
exchange or is this reffering to the multi6/shim signaling handshake? 
 From the answer i guess is the last one but the question is not clear 
to me.

Later on, it is stated that:

                The nature of the
                communication exchange to determine the capability to use
                L3Shim support is not described in [ID.L3SHIM].

agree but some text about this was provided by Jari in

                     [ID.FUNC]  , M. and J. , "Functional Decomposition 
of the M6
                     protocol", Work in progress: Internet Drafts
                     draft-ietf-multi6-functional-dec-00.txt, 2005.

Next, it is stated that:

             How do the endpoints discover the locator set available for
             each other endpoint (locator discovery)?
                The mechanism is by explicit exchange of locator sets
                between the hosts.  The L3Shim description does not
                describe the precise mechanism.

some description about this is also contained in:

         [ID.FUNC]  , M. and J. , "Functional Decomposition of the M6
                     protocol", Work in progress: Internet Drafts
                     draft-ietf-multi6-functional-dec-00.txt, 2005.

Later on in subsection 4.2  Rehoming Triggers it is stated that:

          What triggers can be used to indicate the direction of the
          failed path in order to trigger the appropriate locator repair
          function?

             The [ID.FAIL] description does not provide a description of
             detection of the failed path.  The L3Shim approach attempts
             to treat path failure as a failure of the locator pair,
             rather than failure of a single locator, so the direction of
             the failure is not necessarily critical information in the
             search for a new functional pair.

I am not sure that i understand this part properly, but in section 5.4  
Protocol for Testing Unidirectional Reachability
  of draft-ietf-multi6-failure-detection-00 there is description of a 
failure detection protocol that supports unidirectional paths. So, i 
guess that there is mechanisms to detect which direction is broken, but 
i am not sure this is what you had in mind here....

In section      4.3  Rehoming Locator Pair Selection it is stated that:

             Selection of a specific locator
             pair is based on the successful outcome of a return
             reachability test between the two endpoints.

This is true for destiantion locators but not for the local locator, i 
mean the question being asked is:
         What parameters are used to determine the selection of a
          locator to use to reference the local endpoint?
So i guess this doesn't applies here but it does applies to the next 
question which is:

          If the remote endpoint is multi-homed, what parameters are used
          to determine the selection of a locator to use to reference the
          remote endpoint?

In section 4.4  Locator Change it is stated that:

          What are the preconditions that are necessary for a locator
          change?

             The preconditions necessary is that there has been a
             successful establishment of packets between the two hosts,
             L3Shim capabilities have been successfully negotiated and
             locator sets have been exchanged, and there is an explicit
             trigger for a locator change that has been generated by an
             active transport session.

I think this is not the case
I mean we had some discussions about whether to support the initial 
locator failure as a part of the shim protocol or simply let the 
endpoints to retry using alternative ULID/locators. The point is that 
if this is part of the shim protocol, then apps life will probably be 
easier,and some folks thought that this was a good approach. this means 
that there will be a change of locators without even exchanging 
packets.
A particular case of this situations is the usage of ULAs as ULIDs. 
becuase ULAs are by definition unreachables, so this means that when 
they are used for initaitng the session, this can be seen as a locator 
change

then it is stated that:

          How can the locator change be confirmed by both ends?

             The approach proposed here is by using a return reachability
             test, where a host searches through locator pair selections
             until it receives an explicit acknowledgement of a poll.

This is true for destiantion locators but it is not the case for source 
locators i think. I mean the reachability test is to prevent flooding, 
so a node cannot send traffic to a locator until he is certain that the 
target is willing to receive traffic. However, a node is able to use 
any source locator he wants without performing a reachability test. 
OTOH, it seems reasonable that a node will check if the locator pair is 
reachable before start using it, but this may be optional, and he could 
try using data packets. So, i would say that this is definitely 
mandatory for destiantion locators and optional for source locators.

In subsection       4.5  Removal of Session State

          How is identity / locator binding state removal synchronised
          with session closure?

             As this is a layer 3 function there is no explicit concept
             of sessions.  A L3 Shim mapping state needs to be maintained
             for as long as there is packet activity in either direction.
             The removal of state would most likely be associated with a
             removal eligibility condition associated with a packet
             activity timeout, and an eligible state removal pass being
             undertaken by the L3 Shim statement management module.

Well,  draft-ietf-multi6-functional-dec-00 considers two approaches, 
the coordinated and he uncoordinated. The one that you are describing 
is the uncoordinated, as i understand it, right? I think that there is 
still not a clear choice w.r.t. to this point.

Regards, marcelo