Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
From: marcelo bagnulo braun <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
Date: Sun, 30 Apr 2006 11:43:18 +0300

Thanks Marshall and Scott.
I think it is clear now.

I think there is a case for such proxy service indeed.

Moreover, as i understand it, this special case is probably more 
simpler than the general proxy case that we were discussing previously, 
in particularly security wise.

Let's flesh out the scenario a bit more.

We have a host C located in a soho networks, that is multihomed to two 
small local DSL providers, ISPA and ISPB, that assign PrefA and PrefB 
respectively.

Suppose that the soho client is buying shim6 proxy services from the 
big provider. So the big provider has assigned  PrefC:1:: to the soho 
network
The address of the shim6 proxy is PrefC:proxy

now, in order for this work, i guess that the ULID used by the soho 
host C must be PrefC:1:hostC, and the locator used for any target node 
must be PrefC:proxy

I can think of two possible approaches at this point:

1) Whenever a host inside the soho network wants to establish a new 
communication with a given server S, it establishes a shim6 context 
with the proxy. For that shim6 context the ulid pair is: PrefC:1:hostC 
and IPS and the locator set will be: for Ls(PrefC:1:hostC) = 
(PrefA:hostC, PrefB:hostC) and Ls(IPS)= (PrefC:proxy). the drawback of 
this approach is that we loose the deferred setup capability, which 
imposes a penalty in terms of setup latency and by default shim6 would 
be used for all the communications (we could think of some heuristics 
about for which communication to use the shim6 and for which ones don't 
use it, but this would impact on which ulid use...)

2) an alternative approach would be to create a shim6 protected tunnel 
between the host in the soho network and the shim proxy. In its 
simplest form, it would be a tunnel interface between the host in the 
soho network and the proxy and this interface would be used as a 
default route. The tunnel would then protected by the shim6 protocol 
and fault tolerance features would be available for that path. This 
does not impose additional latency because the tunnel/shim6 context 
would be established at bootstrap and only one tunnel/shim6 context is 
needed to support all the communications. The drawback is that we have 
the tunnel header overhead, but maybe it would be possible to remove 
this using some sort of nested shim (not sure if this last stuff would 
work...) The features provided by the shim in this case would be an 
secure automatic tunnel setup mechanism with fault tolerance 
protection, which may be good enough justification.

I think this second approach is the one that is more attractive...

comments?

regards, marcelo

El 30/04/2006, a las 7:03, Marshall Eubanks escribió:

> Hello;
>
> OK, I'll expound a little.
>
> I work at home and I really needs my Internet connection.
> I can become "multi-homed," (and, in fact, am considering it)
> but let's say I would rather not run  BGP from home.
> So I could get shim6, but what if I find that I
> don't get to use it much, because the content providers I use
> don't support it ? If you come come along and sell me a service / 
> software / hardware to
> fix this, I might buy it.
>
> I use my multihoming and shim6 to get to your equipment in a well 
> provisioned
> colo or exchange point somewhere; from there to the providers is 
> standard
> IP, v6 or maybe even v4, but that's OK because that's all on high 
> capacity
> "backbone" links.
>
>
> On Apr 29, 2006, at 5:19 PM, marcelo bagnulo braun wrote:
>
>>
>> El 29/04/2006, a las 23:21, Marshall Eubanks escribió:
>>
>>>> i am sorry but i am not sure i understand... are you considering 
>>>> the case where the proxy is located in the soho or in the content 
>>>> server network?
>>>
>>> Neither - where the proxy is located on my network.
>>>
>>
>> I am sorry but i am completely lost here...
>>
>> and who's network is this? i mean, is this a provider's network?, i 
>> guess so, but who's provider? the dentist's? and what is the point of 
>> locating a shim proxy in a provider, when you are looking for is 
>> resiliency against provider failures...
>>
>
> I don't know about you, but I am multi-homing my house to protect 
> against MY ISP's failures, not Google's
> or the IETF's or ... . If I have two connections, I can tunnel through 
> both of them
> to some well connected place  which is much less likely to fail (and, 
> through the magic of capitalism, can afford to be much more 
> redundantly connected than I can at home). If the people at the other 
> end don't support shim6
> (and I frankly think that content providers are likely to resist 
> supporting shim6), then, if I can use
> shim6 to this well connected place and a suitable proxy to get the 
> home redundancy I want, I
> may well pay for it, and, if enough people feel the same way, you 
> might have a business.
>
>> thanks, marcelo
>>
>
> You're welcome. Hope this helps, or at least was interesting.
>
> Regards
> Marshall
>
>

Delivery-date: Sun, 30 Apr 2006 04:38:57 +0000
Cc: marcelo bagnulo braun <[email-masked]>, [email-masked], Brian E Carpenter <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sun, 30 Apr 2006 00:38:49 -0400
To: Scott Leibrand <[email-masked]>

Dear Scott;

I think this puts it very well indeed.

Regards
Marshall

On Apr 29, 2006, at 5:51 PM, Scott Leibrand wrote:

> On 04/30/06 at 12:19am +0300, marcelo bagnulo braun  
> <[email-masked]> wrote:
>
>> El 29/04/2006, a las 23:21, Marshall Eubanks escribió:
>>
>>>> i am sorry but i am not sure i understand... are you considering  
>>>> the
>>>> case where the proxy is located in the soho or in the content  
>>>> server
>>>> network?
>>>
>>> Neither - where the proxy is located on my network.
>>
>> I am sorry but i am completely lost here...
>>
>> and who's network is this? i mean, is this a provider's network?, i
>> guess so, but who's provider? the dentist's? and what is the point of
>> locating a shim proxy in a provider, when you are looking for is
>> resiliency against provider failures...
>
> I can't speak for Marshall, but perhaps he's thinking what I'm  
> thinking...
>
> We (Internap) are a massively multihomed ISP/NSP, with each of our  
> sites
> having its own ASN, and having transit connections to roughly 5-8  
> tier 1
> NSPs.  We sell higher performance connectivity than our upstreams can,
> which we can deliver because we optimize our BGP routing to choose the
> best path for every route in our table.
>
> So a logical business for us (or one of our customers), if shim6  
> becomes
> popular with SOHO's but not with content providers, would be to  
> provide a
> third-party shim6 proxy service.  Our proxy would have one IPv6  
> address
> for each of our upstreams, as well as an address out of our own  
> block that
> is advertised via BGP to all of our upstreams.  We could then  
> redirect the
> shim6 traffic to our proxy (via routing and possibly tunneling  
> tricks),
> and perform shim6 context establishment on behalf of a non-shim6- 
> capable
> host if the other side tries to set it up.  We'd likely leave ULID- 
> ULID
> traffic alone, but if a failure is detected REAP would trigger our  
> shim6
> proxy into action, and it could allow the shim6-capable host to  
> rehome to
> a different locator pair.  The traffic from the shim6 proxy to the
> non-shim6-capable host would still rely on BGP to reroute traffic  
> around
> any failures on that path.
>
> -Scott

Delivery-date: Sun, 30 Apr 2006 04:03:30 +0000
Cc: [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sun, 30 Apr 2006 00:03:01 -0400
To: marcelo bagnulo braun <[email-masked]>

Hello;

OK, I'll expound a little.

I work at home and I really needs my Internet connection.
I can become "multi-homed," (and, in fact, am considering it)
but let's say I would rather not run  BGP from home.
So I could get shim6, but what if I find that I
don't get to use it much, because the content providers I use
don't support it ? If you come come along and sell me a service /  
software / hardware to
fix this, I might buy it.

I use my multihoming and shim6 to get to your equipment in a well  
provisioned
colo or exchange point somewhere; from there to the providers is  
standard
IP, v6 or maybe even v4, but that's OK because that's all on high  
capacity
"backbone" links.

On Apr 29, 2006, at 5:19 PM, marcelo bagnulo braun wrote:

>
> El 29/04/2006, a las 23:21, Marshall Eubanks escribió:
>
>>> i am sorry but i am not sure i understand... are you considering  
>>> the case where the proxy is located in the soho or in the content  
>>> server network?
>>
>> Neither - where the proxy is located on my network.
>>
>
> I am sorry but i am completely lost here...
>
> and who's network is this? i mean, is this a provider's network?, i  
> guess so, but who's provider? the dentist's? and what is the point  
> of locating a shim proxy in a provider, when you are looking for is  
> resiliency against provider failures...
>

I don't know about you, but I am multi-homing my house to protect  
against MY ISP's failures, not Google's
or the IETF's or ... . If I have two connections, I can tunnel  
through both of them
to some well connected place  which is much less likely to fail (and,  
through the magic of capitalism, can afford to be much more  
redundantly connected than I can at home). If the people at the other  
end don't support shim6
(and I frankly think that content providers are likely to resist  
supporting shim6), then, if I can use
shim6 to this well connected place and a suitable proxy to get the  
home redundancy I want, I
may well pay for it, and, if enough people feel the same way, you  
might have a business.

> thanks, marcelo
>

You're welcome. Hope this helps, or at least was interesting.

Regards
Marshall

Delivery-date: Sun, 30 Apr 2006 01:22:36 +0000
Content-class: urn:content-classes:message
Subject: RE: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sat, 29 Apr 2006 18:20:47 -0700
From: "Christian Huitema" <[email-masked]>
To: "Scott Leibrand" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>
Cc: "Marshall Eubanks" <[email-masked]>, <[email-masked]>, "Brian E Carpenter" <[email-masked]>

The discussion of target audience appears somewhat linked to the
possibility of supporting multiple IPv6 addresses (or locators) in a
site. We know that the multi-address solution does not scale well to
very large sites. The management burden increases with the number of
hosts and routers, and the potential number of providers and prefixes
also increases with the size of the site. It is fairly clear that, above
a certain size, site managers will insist for their very own "provider
independent" prefix.

Today, we have proof of support for multiple addresses in hosts.
Networking stacks are designed to handle multiple interfaces, and to
manage a different address (or set of addresses) for each interface.
Speaking for the products I know well, the IPv6 stack in XP, Windows
2003 and Vista implements the "strong host" model: by default, the
packets are sent through the interface corresponding to the chosen
source address. This is effectively a form of source address based
routing.

So, we have source address based route selection in the scope of a
single host. This is however a fairly small scope, a bit remote from the
"site multi-homing" goal of shim6. 

It is however relatively easy to imagine how the same model could be
extended to single-subnet sites. If multiple exit routers are attached
to the link, hosts will receive IPv6 router advertisements from each of
these routers, advertising different prefixes. The hosts can configure
as many addresses, and make sure that a different "default gateway" is
associated to each of the different source addresses. This is not
implemented now, but would not be very hard.

That extension would provide support for multi-homing in "single subnet
sites". This is still far from the general goal of supporting generic
site multi-homing, but that would be a first step. The solution would
apply to the home networks, and many small businesses.

I don't know whether we can realistically extend the scope of the
"multiple addresses" support beyond these small sites. In theory,
routers could manage some form of source address based route selection,
e.g. pick different default routes based on the provider prefix in the
source address of packets. But that requires adding the concept of
source based route selection in the intra-domain routing protocols. That
may take some time...

-- Christian Huitema

Delivery-date: Sat, 29 Apr 2006 21:52:29 +0000
Date: Sat, 29 Apr 2006 17:51:48 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Marshall Eubanks <[email-masked]>, [email-masked],  Brian E Carpenter <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)

On 04/30/06 at 12:19am +0300, marcelo bagnulo braun <[email-masked]> wrote:

> El 29/04/2006, a las 23:21, Marshall Eubanks escribió:
>
> >> i am sorry but i am not sure i understand... are you considering the
> >> case where the proxy is located in the soho or in the content server
> >> network?
> >
> > Neither - where the proxy is located on my network.
>
> I am sorry but i am completely lost here...
>
> and who's network is this? i mean, is this a provider's network?, i
> guess so, but who's provider? the dentist's? and what is the point of
> locating a shim proxy in a provider, when you are looking for is
> resiliency against provider failures...

I can't speak for Marshall, but perhaps he's thinking what I'm thinking...

We (Internap) are a massively multihomed ISP/NSP, with each of our sites
having its own ASN, and having transit connections to roughly 5-8 tier 1
NSPs.  We sell higher performance connectivity than our upstreams can,
which we can deliver because we optimize our BGP routing to choose the
best path for every route in our table.

So a logical business for us (or one of our customers), if shim6 becomes
popular with SOHO's but not with content providers, would be to provide a
third-party shim6 proxy service.  Our proxy would have one IPv6 address
for each of our upstreams, as well as an address out of our own block that
is advertised via BGP to all of our upstreams.  We could then redirect the
shim6 traffic to our proxy (via routing and possibly tunneling tricks),
and perform shim6 context establishment on behalf of a non-shim6-capable
host if the other side tries to set it up.  We'd likely leave ULID-ULID
traffic alone, but if a failure is detected REAP would trigger our shim6
proxy into action, and it could allow the shim6-capable host to rehome to
a different locator pair.  The traffic from the shim6 proxy to the
non-shim6-capable host would still rely on BGP to reroute traffic around
any failures on that path.

-Scott

Delivery-date: Sat, 29 Apr 2006 21:19:42 +0000
Cc: [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sun, 30 Apr 2006 00:19:17 +0300
To: Marshall Eubanks <[email-masked]>

El 29/04/2006, a las 23:21, Marshall Eubanks escribió:

>> i am sorry but i am not sure i understand... are you considering the 
>> case where the proxy is located in the soho or in the content server 
>> network?
>
> Neither - where the proxy is located on my network.
>

I am sorry but i am completely lost here...

and who's network is this? i mean, is this a provider's network?, i 
guess so, but who's provider? the dentist's? and what is the point of 
locating a shim proxy in a provider, when you are looking for is 
resiliency against provider failures...

thanks, marcelo

Delivery-date: Sat, 29 Apr 2006 20:22:26 +0000
Cc: [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sat, 29 Apr 2006 16:21:54 -0400
To: marcelo bagnulo braun <[email-masked]>

Hello;

On Apr 29, 2006, at 1:39 PM, marcelo bagnulo braun wrote:

> Hi Marshall,
>
>
> El 28/04/2006, a las 20:32, Marshall Eubanks escribió:
>
>>
>> On Apr 28, 2006, at 11:15 AM, Brian E Carpenter wrote:
>>
>>> Scott Leibrand wrote:
>>>> On 04/20/06 at 1:54pm +0200, Brian E Carpenter  
>>>> <[email-masked]> wrote:
>>>>> Scott Leibrand wrote:
>>>>> ...
>>>>>
>>>>>>> If you don't have source address rewriting, and we assume  
>>>>>>> that ingress
>>>>>>> filters are in place (which seems the by default assumption)  
>>>>>>> then the
>>>>>>> source address selection actually determines the exit path  
>>>>>>> form the
>>>>>>> multihomed site.
>>>>>>
>>>>>> Not in today's networks.  Currently routers route on  
>>>>>> destination address,
>>>>>> not source address, so the destination address selection  
>>>>>> determines which
>>>>>> route is used to route the packets, which in turn determines  
>>>>>> which source
>>>>>> address you have to use if you want your packets to get out.
>>>>>
>>>>> Actually, the sending host could theoretically use a different  
>>>>> default gateway
>>>>> for each different source address. That could be used as a back  
>>>>> door method
>>>>> for choice of exit router, without needing to touch router  
>>>>> behaviour.
>>>> True, for a small network, where all hosts are on the same LAN  
>>>> as the exit
>>>> routers.  I was referring to a larger network with an IGP.
>>>> This seems to me like yet another way that shim6 is designed for  
>>>> small
>>>> sites, and is somewhat less suitable for larger ones.  This isn't
>>>> necessarily a bad thing, as IMO host-based multihoming makes  
>>>> less and less
>>>> sense the larger your site gets, but it seems to be a factor a  
>>>> lot of
>>>> people don't want to accept.
>>>> If we target shim6 at small-site multihoming, for networks that  
>>>> can't do
>>>> BGP-based multihoming today (or would prefer not to for cost), I  
>>>> think we
>>>> have a better shot at getting something actually deployed.  If  
>>>> networks
>>>> like Igor's and Patrick's aren't going to benefit from shim6  
>>>> without
>>>> significant additional state in their servers, they're going to  
>>>> stick with
>>>> BGP multihoming.  If we recognize that, and work to make sure  
>>>> that his
>>>> servers can talk shim6 to multihomed clients with minimal  
>>>> overhead, we'll
>>>> be less likely to get caught in the catch-22 of being unable to get
>>>> traction because one end isn't interested in deploying shim6.
>>>
>>> Right on. Of course a shim6 site can always interoperate in one  
>>> sense
>>> with a non-shim6 site: they can exchange packets, but they can't
>>> switch addresses in the middle of a session. But if all dentists  
>>> offices
>>> run shim6 and all major server sites for dentists don't, the  
>>> added value
>>> of shim6 would be rather limited.
>>>
>>
>> I actually suspect that there might be a proxy business develop  
>> for shim6 (assuming it gets
>> off the ground, etc.). In Brian's case, I could set up boxes in a  
>> colo with really
>> good bandwidth and (PI or PA) multihoming, the Dentists shim6 to  
>> me, I do a conventional multihome to
>> their providers, and everyone is happy. I have thought for a while  
>> that this could drive
>> shim6 deployment fast into the SOHO market if it could be  
>> developed and made rock solid.
>>
>
> i am sorry but i am not sure i understand... are you considering  
> the case where the proxy is located in the soho or in the content  
> server network?

Neither - where the proxy is located on my network.

>
> thanks, marcelo
>
>
>>
>>>     Brian
>>>
>>
>> Marshall
>>
>

Regards
Marshall

Delivery-date: Sat, 29 Apr 2006 17:40:31 +0000
Cc: [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Sat, 29 Apr 2006 20:39:05 +0300
To: Marshall Eubanks <[email-masked]>

Hi Marshall,

El 28/04/2006, a las 20:32, Marshall Eubanks escribió:

>
> On Apr 28, 2006, at 11:15 AM, Brian E Carpenter wrote:
>
>> Scott Leibrand wrote:
>>> On 04/20/06 at 1:54pm +0200, Brian E Carpenter <[email-masked]> 
>>> wrote:
>>>> Scott Leibrand wrote:
>>>> ...
>>>>
>>>>>> If you don't have source address rewriting, and we assume that 
>>>>>> ingress
>>>>>> filters are in place (which seems the by default assumption) then 
>>>>>> the
>>>>>> source address selection actually determines the exit path form 
>>>>>> the
>>>>>> multihomed site.
>>>>>
>>>>> Not in today's networks.  Currently routers route on destination 
>>>>> address,
>>>>> not source address, so the destination address selection 
>>>>> determines which
>>>>> route is used to route the packets, which in turn determines which 
>>>>> source
>>>>> address you have to use if you want your packets to get out.
>>>>
>>>> Actually, the sending host could theoretically use a different 
>>>> default gateway
>>>> for each different source address. That could be used as a back 
>>>> door method
>>>> for choice of exit router, without needing to touch router 
>>>> behaviour.
>>> True, for a small network, where all hosts are on the same LAN as 
>>> the exit
>>> routers.  I was referring to a larger network with an IGP.
>>> This seems to me like yet another way that shim6 is designed for 
>>> small
>>> sites, and is somewhat less suitable for larger ones.  This isn't
>>> necessarily a bad thing, as IMO host-based multihoming makes less 
>>> and less
>>> sense the larger your site gets, but it seems to be a factor a lot of
>>> people don't want to accept.
>>> If we target shim6 at small-site multihoming, for networks that 
>>> can't do
>>> BGP-based multihoming today (or would prefer not to for cost), I 
>>> think we
>>> have a better shot at getting something actually deployed.  If 
>>> networks
>>> like Igor's and Patrick's aren't going to benefit from shim6 without
>>> significant additional state in their servers, they're going to 
>>> stick with
>>> BGP multihoming.  If we recognize that, and work to make sure that 
>>> his
>>> servers can talk shim6 to multihomed clients with minimal overhead, 
>>> we'll
>>> be less likely to get caught in the catch-22 of being unable to get
>>> traction because one end isn't interested in deploying shim6.
>>
>> Right on. Of course a shim6 site can always interoperate in one sense
>> with a non-shim6 site: they can exchange packets, but they can't
>> switch addresses in the middle of a session. But if all dentists 
>> offices
>> run shim6 and all major server sites for dentists don't, the added 
>> value
>> of shim6 would be rather limited.
>>
>
> I actually suspect that there might be a proxy business develop for 
> shim6 (assuming it gets
> off the ground, etc.). In Brian's case, I could set up boxes in a colo 
> with really
> good bandwidth and (PI or PA) multihoming, the Dentists shim6 to me, I 
> do a conventional multihome to
> their providers, and everyone is happy. I have thought for a while 
> that this could drive
> shim6 deployment fast into the SOHO market if it could be developed 
> and made rock solid.
>

i am sorry but i am not sure i understand... are you considering the 
case where the proxy is located in the soho or in the content server 
network?

thanks, marcelo

>
>>     Brian
>>
>
> Marshall
>

Delivery-date: Fri, 28 Apr 2006 17:32:55 +0000
Cc: Scott Leibrand <[email-masked]>, marcelo bagnulo braun <[email-masked]>, [email-masked]
From: Marshall Eubanks <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Fri, 28 Apr 2006 13:32:34 -0400
To: Brian E Carpenter <[email-masked]>

On Apr 28, 2006, at 11:15 AM, Brian E Carpenter wrote:

> Scott Leibrand wrote:
>> On 04/20/06 at 1:54pm +0200, Brian E Carpenter  
>> <[email-masked]> wrote:
>>> Scott Leibrand wrote:
>>> ...
>>>
>>>>> If you don't have source address rewriting, and we assume that  
>>>>> ingress
>>>>> filters are in place (which seems the by default assumption)  
>>>>> then the
>>>>> source address selection actually determines the exit path form  
>>>>> the
>>>>> multihomed site.
>>>>
>>>> Not in today's networks.  Currently routers route on destination  
>>>> address,
>>>> not source address, so the destination address selection  
>>>> determines which
>>>> route is used to route the packets, which in turn determines  
>>>> which source
>>>> address you have to use if you want your packets to get out.
>>>
>>> Actually, the sending host could theoretically use a different  
>>> default gateway
>>> for each different source address. That could be used as a back  
>>> door method
>>> for choice of exit router, without needing to touch router  
>>> behaviour.
>> True, for a small network, where all hosts are on the same LAN as  
>> the exit
>> routers.  I was referring to a larger network with an IGP.
>> This seems to me like yet another way that shim6 is designed for  
>> small
>> sites, and is somewhat less suitable for larger ones.  This isn't
>> necessarily a bad thing, as IMO host-based multihoming makes less  
>> and less
>> sense the larger your site gets, but it seems to be a factor a lot of
>> people don't want to accept.
>> If we target shim6 at small-site multihoming, for networks that  
>> can't do
>> BGP-based multihoming today (or would prefer not to for cost), I  
>> think we
>> have a better shot at getting something actually deployed.  If  
>> networks
>> like Igor's and Patrick's aren't going to benefit from shim6 without
>> significant additional state in their servers, they're going to  
>> stick with
>> BGP multihoming.  If we recognize that, and work to make sure that  
>> his
>> servers can talk shim6 to multihomed clients with minimal  
>> overhead, we'll
>> be less likely to get caught in the catch-22 of being unable to get
>> traction because one end isn't interested in deploying shim6.
>
> Right on. Of course a shim6 site can always interoperate in one sense
> with a non-shim6 site: they can exchange packets, but they can't
> switch addresses in the middle of a session. But if all dentists  
> offices
> run shim6 and all major server sites for dentists don't, the added  
> value
> of shim6 would be rather limited.
>

I actually suspect that there might be a proxy business develop for  
shim6 (assuming it gets
off the ground, etc.). In Brian's case, I could set up boxes in a  
colo with really
good bandwidth and (PI or PA) multihoming, the Dentists shim6 to me,  
I do a conventional multihome to
their providers, and everyone is happy. I have thought for a while  
that this could drive
shim6 deployment fast into the SOHO market if it could be developed  
and made rock solid.

>     Brian
>

Marshall

Delivery-date: Fri, 28 Apr 2006 15:16:35 +0000
Date: Fri, 28 Apr 2006 17:15:35 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Scott Leibrand <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)

Scott Leibrand wrote:
> On 04/20/06 at 1:54pm +0200, Brian E Carpenter <[email-masked]> wrote:
> 
> 
>>Scott Leibrand wrote:
>>...
>>
>>>>If you don't have source address rewriting, and we assume that ingress
>>>>filters are in place (which seems the by default assumption) then the
>>>>source address selection actually determines the exit path form the
>>>>multihomed site.
>>>
>>>Not in today's networks.  Currently routers route on destination address,
>>>not source address, so the destination address selection determines which
>>>route is used to route the packets, which in turn determines which source
>>>address you have to use if you want your packets to get out.
>>
>>Actually, the sending host could theoretically use a different default gateway
>>for each different source address. That could be used as a back door method
>>for choice of exit router, without needing to touch router behaviour.
> 
> 
> True, for a small network, where all hosts are on the same LAN as the exit
> routers.  I was referring to a larger network with an IGP.
> 
> This seems to me like yet another way that shim6 is designed for small
> sites, and is somewhat less suitable for larger ones.  This isn't
> necessarily a bad thing, as IMO host-based multihoming makes less and less
> sense the larger your site gets, but it seems to be a factor a lot of
> people don't want to accept.
> 
> If we target shim6 at small-site multihoming, for networks that can't do
> BGP-based multihoming today (or would prefer not to for cost), I think we
> have a better shot at getting something actually deployed.  If networks
> like Igor's and Patrick's aren't going to benefit from shim6 without
> significant additional state in their servers, they're going to stick with
> BGP multihoming.  If we recognize that, and work to make sure that his
> servers can talk shim6 to multihomed clients with minimal overhead, we'll
> be less likely to get caught in the catch-22 of being unable to get
> traction because one end isn't interested in deploying shim6.

Right on. Of course a shim6 site can always interoperate in one sense
with a non-shim6 site: they can exchange packets, but they can't
switch addresses in the middle of a session. But if all dentists offices
run shim6 and all major server sites for dentists don't, the added value
of shim6 would be rather limited.

     Brian

Delivery-date: Fri, 28 Apr 2006 12:47:22 +0000
Cc:  <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: locator pair selection (was Re: continued review of /draft-ietf-shim6-failure-detection-03.txt
Date: Fri, 28 Apr 2006 15:47:15 +0300
To:  <[email-masked]>

Hi John,

One comment w.r.t. one of the points you make below...

El 28/04/2006, a las 15:17, <[email-masked]> escribió:

>
> Section 5.3:
>
>    Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
>    what combinations of addresses are allowed from a local point of
>    view, as this reduces the search space.
>
> RFC 3484 is "default address selection"; I would hesitate to make this
> a MUST.  I would say that 3484 is the default mechanism for REAP, but
> surely nodes can have an optimized algorithm?
>

I agree with respect to this point.
probably when selecting the locators pairs to be explored, we need to:
- consider the issues included in RFC3484 but probably with a different  
priority
- consider other information, like reachability, preferenes and so on,  
available from the shim6 protocol

I have wrote a mechanism for locator pair selection that takes into  
account this additional issues.

I haven't submitted it yet, but you can find it in:

http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-locator-pair- 
selection-00.txt

perhaps this could be a useful tool...

regards, marcelo

Delivery-date: Fri, 28 Apr 2006 12:19:25 +0000
Content-class: urn:content-classes:message
Subject: continued review of /draft-ietf-shim6-failure-detection-03.txt
Date: Fri, 28 Apr 2006 15:17:46 +0300
From: <[email-masked]>
To: <[email-masked]>

continued from where I left off.

Section 5.2:

   Upon changing to a new address pair, transport layer protocol needs
   to be informed so that it can perform a slow start, or some other
   form of adaptation to the possibly changed conditions.  However, this
   functionality is outside the scope of REAP and is rather seen as a
   general multihoming issue.

Slow start is really for TCP, probably you should generalize this to
say:

   Upon changing to a new address pair, the network path traversed most
likely
   has changed, so that the ULP SHOULD be informed. This can be a signal
   for the ULP to adapt due to the change in path so that, for example,
   TCP could initiate a slow start procedure.

or something along those lines.

5.3.  Exploration Order

   The exploration process assumes an ability to pick current and
   alternative address pairs.  

The above sentence doesn't parse ... do you mean "... and use an 
alternative address pair."?

Section 5.3:

   Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
   what combinations of addresses are allowed from a local point of
   view, as this reduces the search space. 

RFC 3484 is "default address selection"; I would hesitate to make this
a MUST.  I would say that 3484 is the default mechanism for REAP, but
surely nodes can have an optimized algorithm?

Section 5.3:

   One suggested good implementation strategy is to record the
   reachability test result (an on/off value) and multiply this by the
   age of the information.  This allows recently tested address pairs to
   be chosen before old ones.

This suggestion confuses me.  If reachable = 1 and unreachable = 0;
multiplying
it by the age of the information, I guess we'd like to choose the lowest
non-zero
value ... but I suggest deleting this text, unless you want to make a
more formal
algorithm for this action.

Section 5.3:

   Out of the set of possible candidate address pairs, nodes SHOULD
   attempt a test through all of them until a working pair is found, and
   retrying the process as is necessary.  However, all nodes MUST
   perform this process sequentially and with exponential back-off.
   This sequential process is necessary in order to avoid a "signaling
   storm" when an outage occurs (particularly for a complete site).
   However, it also limits the number of addresses that can in practice
   be used for multihoming, considering that transport and application
   layer protocols will fail if the switch to a new address pair takes
   too long.

I know you are describing a general procedure, but I think this protocol
needs
some suggest timer values, etc.  'as is ncessary' isn't sufficient.  If
you 
define timers elsewhere, then put a forward reference to the section,
please.

Section 5.4

   REAP is designed as a modular part of SHIM6 in the hopes that it may
   also be useful in other contexts. 

This sentence doesn't make sense - you designed it to be a modular part
of SHIM6
so that it might be useful in other contexts?  I think you mean it is
not included
in the base shim6, but as a stand-alone, modular protocol as it may have
potential
uses for other protocols ....

6.1.  Keepalive Message

Missing explanations of the  Hdr Ext Len, Checksum fields.

====
NOTE: 
I'm holding off on a full protocol review until a revision, it looks
basically like it could work.

====

7. Security Considerations

I think you should say that REAP SHOULD NOT rely on unverified "various
indications from 
lower layers" etc. to determine connectivity or failure, as they may be
spoofed.

=== 

General comment - lots of text in the document is somewhat speculative,
esp. the use
of REAP in other scenarios.  I'd probably tighten-up this language.
Designing the
protocol to a modular piece of SHIM6 is a good idea, but speculating
that it could
be used elsewhere seems inappropriate.  If you want to design it as a
completely standalone
protocol, then that should be done - though I would not recommend that
option.

John

Delivery-date: Wed, 26 Apr 2006 13:41:40 +0000
Cc: <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Wed, 26 Apr 2006 16:41:22 +0300
To: <[email-masked]>

El 26/04/2006, a las 11:09, <[email-masked]> escribió:

> Marcelo,
>
>>> I think we should drop the '... may be used in other contexts.' as
>>> this seems outside of the scope of SHIM6. I don't think that SHIM6
>>> should work on a general purpose failure detection & path exploration
>
>>> protocol.
>>
>> I think that there are several scenarios where there seems to be the
>> need for having a protocol for detecting failures and exploring
>> alternative paths. For instance, in mobile IP, there is no way to
>> determine if the current CoA is working and explore alternative coas 
>> if
>
>> a failure is detected. Similar thing happens in HIP for instance.
>>
>> So, my take on this is that perhaps it would be good if the failure
>> detection and alternative path exploration protocols defined by shim6
>> could be reused in such scenarios (of course if this does not implies
>> giving up functionality, but i don't think this is the case)
>>
>> I mean, if we can define a single protocol that can be used in 
>> multiple
>
>> scenarios that need the same functionality i think it makes sense....
>
> It makes sense, but the devil's in the details.  Many (most?) protocols
> running over IP or UDP have some failure detection mechanism - usually
> by using of keep-alives.

well, MIP does not have one at the moment and imho this is something 
needed in there
HIP is in a similar situation AFAIK

>   I'm not sure if SHIM6 is the place to do this
> general purpose failure detection & path exploration protocol; perhaps
> the chairs can comment.
>
> Anyhow, I imagine that SHIM6, MobIKE, HIP, etc. might have slightly
> different
> needs or requirements for this kind of functionality and how do we
> ensure
> that we don't over-engineer a solution but make sure it covers the 
> needs
> of protocols outside of SHIM6.

i fully agree with this, i would do this only if it is for free (or 
very reduced cost)
i wouldn't want to spend additional effort to accomodate the needs of n 
different protocols here.

but if we do the faildet protocol and we aimed to be an as general as 
possible protocol, then maybe the result can be reused somewhere else.

i think we are quite there already, i mean the faildet draft is quite 
general imho and could easily fit the needs of MIP and HIP AFAICT

Regards, marcelo

>
> John
>

Delivery-date: Wed, 26 Apr 2006 13:24:46 +0000
Date: Wed, 26 Apr 2006 16:23:44 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: IPR declaration regarding the HBA/CGA usage in the HBA draft

This IPR declaration has been recently filed
by Ericsson:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_idq1

Delivery-date: Wed, 26 Apr 2006 08:09:30 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-shim6-failure-detection-03.txt
Date: Wed, 26 Apr 2006 11:09:06 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Marcelo,

>> I think we should drop the '... may be used in other contexts.' as 
>> this seems outside of the scope of SHIM6. I don't think that SHIM6 
>> should work on a general purpose failure detection & path exploration

>> protocol.
>
>I think that there are several scenarios where there seems to be the 
>need for having a protocol for detecting failures and exploring 
>alternative paths. For instance, in mobile IP, there is no way to 
>determine if the current CoA is working and explore alternative coas if

>a failure is detected. Similar thing happens in HIP for instance.
>
>So, my take on this is that perhaps it would be good if the failure 
>detection and alternative path exploration protocols defined by shim6 
>could be reused in such scenarios (of course if this does not implies 
>giving up functionality, but i don't think this is the case)
>
>I mean, if we can define a single protocol that can be used in multiple

>scenarios that need the same functionality i think it makes sense....

It makes sense, but the devil's in the details.  Many (most?) protocols
running over IP or UDP have some failure detection mechanism - usually 
by using of keep-alives.  I'm not sure if SHIM6 is the place to do this
general purpose failure detection & path exploration protocol; perhaps
the chairs can comment.

Anyhow, I imagine that SHIM6, MobIKE, HIP, etc. might have slightly
different
needs or requirements for this kind of functionality and how do we
ensure
that we don't over-engineer a solution but make sure it covers the needs
of protocols outside of SHIM6.

John

Delivery-date: Wed, 26 Apr 2006 07:46:00 +0000
Cc: [email-masked], kurt Erik Lindqvist <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01
Date: Wed, 26 Apr 2006 10:44:48 +0300
To: Geoff Huston <[email-masked]>

Hi,

thanks for the review and for forwarding it...

in general terms, i understand that the summary of the discussion is  
about whether we need a shim6 specific security mechanism like HBA or  
we can handle this with other more general purpose mechanisms.

As i understand it, during the discussions about the security approach,  
it was deemed that it was very important to have an optimized  
performance for the shim protocol and that the security solution didn't  
impose much additional performance penalties. I guess we agree that HBA  
are as efficient as we can get, since they only require a hash  
operation for generation and for verification. The usage of approaches  
based on public key are clearly a couple of orders more expensive. I  
guess this is critical, since the verifications need to be performed  
for each shim6 session. From the reading of lately discussions about  
the load imposed by the shim6 protocol in heavy loaded servers, i think  
that this issue becomes particularly relevant, since using an  
efficient/computationally cheap method in those servers will reduce the  
computational load imposed to them considerably.

I mean, i think that an important thing to note is that shim6 is not  
used as other security mechanisms like BTNS when additional security is  
needed, but is is expected to be used in most of the communications.  
This means that any performance penalty that is added because of  
security will affect most of the communications (as oposed to only  
those that require special security). In other words, in other  
scenarios, where people are looking for enhanced security, they are  
likely to pay the additional cost that it implies. However, in this  
case, these are regular communications, so imposing a high performance  
cost due to security is harder to accept i guess.

In addition, i think it is important to note that HBA are defined as an  
extension to CGAs so actually the verification needed for HBA are  
actually a subset of the verification needed for CGA, since you only  
need to generate the address to verify the validity while in the CGA  
case, you need to generate the address and then verify the signature.

So, imho, the performance gain justifies the need for a specific  
security mechanism, especially considering some scenarios where  
performance is critical and where turning on the shim shouldn't impose  
important performance penalties to the server.

Additional detailed comments below...

El 25/04/2006, a las 18:11, Geoff Huston escribió:

> Hi,
>
> We'd like to interject on this list with a piece of shim6 working  
> group business.
>
> Some months back this working group concluded a last call on   
> draft-ietf-shim6-hba, the hash based-address draft. This draft was  
> passed to the Internet Area Directors, but it was agreed that the  
> document would be parked with the area directors until the protocol  
> and failure drafts also made it through WG Last Call.
>
> We'd like to ask the working group at this stage if there are any  
> further thoughts about the hash based address draft in the light of a  
> security directorate review of the draft. The message thread of that  
> review is attached to this note. (The review was conducted in November  
> and December last year)
>
> So are there any WG comments related to this security directorate  
> review please?
>
> regards,
>
>     Geoff & Kurtis
>
> ---------------------------------
>
>
>
>
>
>
> From: Eric Rescorla <[email-masked]>
>
>
> I've just finished reading draft-ietf-shim6-hba-10: "Hash Based  
> Addresses"
>
> GENERAL COMMENTS ON THE MECHANISM
> The basic goal of this draft is to securely bind together multiple
> IPv6 addresses that belong to the same multihomed host. This allows
> rerouting of traffic without worrying that you're being redirected
> to an attacker. The technique that's used is to use a hash of the
> permitted prefixes in the low order bits of the v6 address.
>
> So, eliding some details, say you have prefixes A, B, C, and D, you
> would generate a prefix list P consisting of (A,B,C,D). Then you would
> generate the new addresses:
>
>     A || H(A || P)
>     B || H(B || P)
>     B || H(C || P)
>     D || H(D || P)
>
> Thus, given one valid address out of the group and the prefix list P  
> you
> can determine whether another address is part of the group by computing
> the hash and checking against the low order bits.
>
> For me, the big unanswered question is why this is a good general
> approach.

the answer to this question is performance
see above considerations

>  Far preferable, IMO, would be to simply to cryptographically
> sign the prefix list using some key bound to the association.
> This key could be established in a number of ways, including
> something like BTNS or CGA. This would have a number of advantages:
>
> (1) A more standard style mechanism.

well, HBA is heavily based on CGA
actually the generation and verification mechanisms are the CGA  
methods, only that they need to be performed several times instead of  
one.
Since the HBA has been defined as a CGA extension, generating the CGAs  
including the HBA extension results in generating the HBAs. Moreover,  
this is already supported in the current CGA spec, since it does  
contain support for extensiosn, and it does states that they must be  
included in the hash calculations

> (2) Not tied to SHA-1.

but CGAs are the ones tied to SHA-1 rather than HBA
HBAs are tied to SHA-1 because they are defined as a CGA extension. so  
moving to CGAs wouldn't address this issue

> (3) Doesn't get progressively weaker due to Moore's law, since you
>     can continue to increase your key size. By contrast, this scheme
>     has an absolute upper security limit of 2^64.

two comments:
- first, as JAri mentions below, there is the Sec parameter to deal  
with this
- second, the weakest link in the chain is the 59 bits of hash  
contained in the iid. so CGAs and HBA are equally weak and increasing  
the key length of the CGA does not provides additional security,  
because the weak part is the number of iid bits

> (4) Can add new prefixes in real-time.
>

that is true, but with the additional perfrmance penalty

> This draft does not make clear what advantages the described scheme
> has.
>

I can try to add some comments about the motivation for this, in the  
lines of performance and use cases

> It's also worth noting that if you're using IPsec, you have a lot of
> other options that are even better.
>

better in which sense?

more secure? not sure how wihtout using a PKI scheme... i mean if you  
want to use locators as ULIDs, which seems to be the case in order not  
to break some apps and other stuff you have two options AFAICT:
- include crypto information in the iid (so hba is as secure as you can  
get i guess)
- use certificates (or another third trusted party) to secure the  
binding... i think that the deployment issues involved with this are  
really big, so we decided not to go thorugh this path

>
> COMMENTS ON THE DOCUMENT
> This document needs a lot more abstract up-front material.
> I recommend adding:
>
> (1) A section on the threat model.

well, there is a RFC4218 that is referenced a couple of times, which  
contains the threat analysis, and in addition, there is the security  
considerations that explains what an attacker needs to do to actually  
attack the HBAs... so i am not sure what to add... any suggestions?

> (2) Explanation of why this is a desirable approach.

yes, i can add a parragraph about performance issues and use cases

> (3) An abstract description of the mechanism, as shown above.
>     S 4,5 have way too much detail to be this, and, it's actually
>     distracting.
>

ok, do you mind if i borrow your text above?

>
> S 4:
> I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
> terms for SHA-1.
>

ok

> Why are three collisions a boundary here in step 6.4. Have you
> analyzed the chance of this happening? Why not just continue
> until you're out of collision bits.
>

this is taken from the CGA spec, so in order to change this we need to  
change this we need to change RFC3972

> S 5.
> I found paragraph 2 here fairly awkward. As I understand it,
> the point here is to justify the replacement in step 1, but
> maybe a rewrite is in order? Sorry I can't be of too much help
> here, but no new text comes to mind.
>

ok, i will to rewrite it

> Is Sec in the packet? If so, what stops an attacker setting it
> to zero?
>

Sec is included in the address itself, so changing the Sec implies  
changing the address

>
> S 9.
> Given that this mechanism is tied irrevocably to SHA-1, it seems
> appropriate to discuss what properties of SHA-1 you require.
>

fully agree, but i guess that what is needed is a general anlysis for  
CGAs rather than one special for HBA...

>
> ----------------------------------------------------------------------- 
> -------
>
> From: Sam Hartman <[email-masked]>
>
> I've forwarded your review to Margaret as she requested the review.
>
>
> There is a threat model for the general problem space which I believe
> is sufficient for thinking about this document.  Take a look at RFC
> 4218.  I seem to recall it is quite well written as these things go.
>
>
> So, roughly, here are my first cut at requirements for a solution.
> This is off the top of my head.  I am not up to speed on shim6; they
> may actually have requirements written out.
>

Yes, RFC4218 and i think it covers all the threats...

> 1) You want to have a efficient mechanism for authenticating that
>    traffic is going to a valid place.
>
> 2) You don't want attackers who were once on-path to be able to direct
>    traffic to themselves.
>
> 3) You don't want off-path attackers to be able to direct traffic to
>    themselves at all.
>
> 4) You don't want on-path attackers to be able to influence traffic
>    such that it goes to them and not the original destination.
>    I.E. if I'm on the path and also have some tunnel address you
>    woludn't see I should not be able to redirect your traffic to my
>    tunnel and thus capture it.
>
> the requirement for efficient probably rules out DH and any public-key
> key agreement algorithm.  The requirement for deployable rules out
> anything that assumes preconfiguration.
>
>
> So, you don't start out with a secret.  You can trivially have a
> secret from off-path attackers simply by sending the secret over the
> connection.  (I hesitate to call that a secret, but it would at least
> be a quantity unknown by people off-path).
>
>
> However there's very little you can do about the on-path people.  I
> think the only thing you can do is commit to some quanity so that an
> on-path attacker cannot add addresses.
>

yes, the problem are basically future/time-shifted attacks...

AFAICT, HBAs are the candidate to provide protection against these  
attacks without using public key crypto...

Regards, marcelo

>
> I'd be very interested in other ways of looking at this because I do
> agree with your concerns about HBA.
>
> --Sam
>

Delivery-date: Tue, 25 Apr 2006 17:31:47 +0000
Date: Tue, 25 Apr 2006 20:29:29 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Geoff Huston <[email-masked]>
cc: [email-masked], marcelo bagnulo braun <[email-masked]>, kurt Erik Lindqvist <[email-masked]>
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01

On Wed, 26 Apr 2006, Geoff Huston wrote:
> We'd like to ask the working group at this stage if there are any further 
> thoughts about the hash based address draft in the light of a security 
> directorate review of the draft. The message thread of that review is 
> attached to this note. (The review was conducted in November and December 
> last year)

I must wonder what has happened in the intervening 5 (or so) months..

But aside from that, EKR wrote:
"A single digital signature that's checked every time you re-home 
seems quite eminently practical."

I may be a bit dense right now, but I'd like to see at least a sketch 
how that would work.  In particular, Im not sure how that is bound to 
the address so that on-path moving off-path wouldn't cause a 
time-shifting attack.

That said, the HBA's "all addresses must change if one changes" is 
rather onerous, so it could be beneficial if we could make do with 
just CGA.

Note: CGA when used with shim6 doesn't have RF IPR license.

-- 
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: Tue, 25 Apr 2006 15:12:52 +0000
Date: Wed, 26 Apr 2006 01:11:11 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: [secdir]Comments on draft-ietf-shim6-hba-01
Cc: marcelo bagnulo braun <[email-masked]>, kurt Erik Lindqvist <[email-masked]>

Hi,

We'd like to interject on this list with a piece of shim6 working group 
business.

Some months back this working group concluded a last call 
on  draft-ietf-shim6-hba, the hash based-address draft. This draft was 
passed to the Internet Area Directors, but it was agreed that the document 
would be parked with the area directors until the protocol and failure 
drafts also made it through WG Last Call.

We'd like to ask the working group at this stage if there are any further 
thoughts about the hash based address draft in the light of a security 
directorate review of the draft. The message thread of that review is 
attached to this note. (The review was conducted in November and December 
last year)

So are there any WG comments related to this security directorate review 
please?

regards,

     Geoff & Kurtis

---------------------------------

From: Eric Rescorla <[email-masked]>

I've just finished reading draft-ietf-shim6-hba-10: "Hash Based Addresses"

GENERAL COMMENTS ON THE MECHANISM
The basic goal of this draft is to securely bind together multiple
IPv6 addresses that belong to the same multihomed host. This allows
rerouting of traffic without worrying that you're being redirected
to an attacker. The technique that's used is to use a hash of the
permitted prefixes in the low order bits of the v6 address.

So, eliding some details, say you have prefixes A, B, C, and D, you
would generate a prefix list P consisting of (A,B,C,D). Then you would
generate the new addresses:

     A || H(A || P)
     B || H(B || P)
     B || H(C || P)
     D || H(D || P)

Thus, given one valid address out of the group and the prefix list P you
can determine whether another address is part of the group by computing
the hash and checking against the low order bits.

For me, the big unanswered question is why this is a good general
approach. Far preferable, IMO, would be to simply to cryptographically
sign the prefix list using some key bound to the association.
This key could be established in a number of ways, including
something like BTNS or CGA. This would have a number of advantages:

(1) A more standard style mechanism.
(2) Not tied to SHA-1.
(3) Doesn't get progressively weaker due to Moore's law, since you
     can continue to increase your key size. By contrast, this scheme
     has an absolute upper security limit of 2^64.
(4) Can add new prefixes in real-time.

This draft does not make clear what advantages the described scheme
has.

It's also worth noting that if you're using IPsec, you have a lot of
other options that are even better.

COMMENTS ON THE DOCUMENT
This document needs a lot more abstract up-front material.
I recommend adding:

(1) A section on the threat model.
(2) Explanation of why this is a desirable approach.
(3) An abstract description of the mechanism, as shown above.
     S 4,5 have way too much detail to be this, and, it's actually
     distracting.

S 4:
I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
terms for SHA-1.

Why are three collisions a boundary here in step 6.4. Have you
analyzed the chance of this happening? Why not just continue
until you're out of collision bits.

S 5.
I found paragraph 2 here fairly awkward. As I understand it,
the point here is to justify the replacement in step 1, but
maybe a rewrite is in order? Sorry I can't be of too much help
here, but no new text comes to mind.

Is Sec in the packet? If so, what stops an attacker setting it
to zero?

S 9.
Given that this mechanism is tied irrevocably to SHA-1, it seems
appropriate to discuss what properties of SHA-1 you require.

------------------------------------------------------------------------------

From: Sam Hartman <[email-masked]>

I've forwarded your review to Margaret as she requested the review.

There is a threat model for the general problem space which I believe
is sufficient for thinking about this document.  Take a look at RFC
4218.  I seem to recall it is quite well written as these things go.

So, roughly, here are my first cut at requirements for a solution.
This is off the top of my head.  I am not up to speed on shim6; they
may actually have requirements written out.

1) You want to have a efficient mechanism for authenticating that
    traffic is going to a valid place.

2) You don't want attackers who were once on-path to be able to direct
    traffic to themselves.

3) You don't want off-path attackers to be able to direct traffic to
    themselves at all.

4) You don't want on-path attackers to be able to influence traffic
    such that it goes to them and not the original destination.
    I.E. if I'm on the path and also have some tunnel address you
    woludn't see I should not be able to redirect your traffic to my
    tunnel and thus capture it.

the requirement for efficient probably rules out DH and any public-key
key agreement algorithm.  The requirement for deployable rules out
anything that assumes preconfiguration.

So, you don't start out with a secret.  You can trivially have a
secret from off-path attackers simply by sending the secret over the
connection.  (I hesitate to call that a secret, but it would at least
be a quantity unknown by people off-path).

However there's very little you can do about the on-path people.  I
think the only thing you can do is commit to some quanity so that an
on-path attacker cannot add addresses.

I'd be very interested in other ways of looking at this because I do
agree with your concerns about HBA.

--Sam

_______________________________________________

From: Jari Arkko <[email-masked]>

Hi Eric,

Continuing the discussion on some of the points
you raised:

>For me, the big unanswered question is why this is a good general
>approach. Far preferable, IMO, would be to simply to cryptographically
>sign the prefix list using some key bound to the association.
>This key could be established in a number of ways, including
>something like BTNS or CGA. This would have a number of advantages:
>
I guess the main question is "what association". In
situations where we have actual managed security
relationship, such as in VPNs, we already have IKEv2
and MOBIKE which do more or less the same function
as SHIM6 does, so there's really no need for additional
support in IPv6 for this purpose. However, this is not
the only scenario people have. SHIM6 targets more
general Internet usage which does not assume managed
security between corresponding hosts. But I think
we agree on this, the question is on how to achieve
it. The possibilities that come to my mind are

  - HBAs
  - CGAs
  - BTNS

SHIM6 is taking the approach which uses HBAs or optionally
CGAs. Another possible option would have been to use only
CGAs. I believe the discussions that led to doing HBA related
to computational cost, and IPRs. However, I'm personally
not very convinced about the computational cost problem.
For one thing, I think you only need to do the computations
IF you actually end up having a connectivity problem and
have to switch the address. (There was also some confusion
in the WG I think about the CGA public key computation
implying "PKI" but I hope that was not the reason people
wanted to have symmetric scheme like HBA...) And then
there are IPR on CGA by Ericsson and Microsoft, maybe that
was a part of the rationale for choosing mandatory HBA. But
I have not personally looked at the actual patents so
I at least do not know if the simpler HBA scheme really
falls outside the scope of the claims. Also, there was a
free license for SEND use of CGA by the IPR holders, so
that might be something to try here too.

BTNS would be the other option. However, while
I think BTNS does a good job in the channel binding
case I'm much less convinced that we know what it
should or could do in other cases. In fact, I do not
currently see how to make it work for something like
what SHIM6 wants to do. Maybe we can make it work,
but its really not there today. Getting it done would
be very useful, though, particularly if BTNS+MOBIKE would
give us SHIM6-like functionality but have it also work for v4
and over NATs...

>(2) Not tied to SHA-1.
>
The SHA-1 issue is by the way something that applies
not just to this proposal but also to CGAs as defined for
SEND. I'd like to see an effort try to get rid of SHA-1
in CGA. If the CGA format is changed then this draft's
use of SHA-1 would also be fixed.

>(3) Doesn't get progressively weaker due to Moore's law, since you
>    can continue to increase your key size. By contrast, this scheme
>    has an absolute upper security limit of 2^64.
>
I believe HBA uses the same "Sec" extension scheme as
CGA does, see Section 7.2 in RFC 3972. That is, the
difference between the effort of the owner and attacker
is always 2^59, but the actual effort can be adjusted.

--Jari

_______________________________________________

From: Eric Rescorla <[email-masked]>

Sam Hartman <[email-masked]> writes:

 > I've forwarded your review to Margaret as she requested the review.
 >
 >
 > There is a threat model for the general problem space which I believe
 > is sufficient for thinking about this document.  Take a look at RFC
 > 4218.  I seem to recall it is quite well written as these things go.

Willdo.

 > So, roughly, here are my first cut at requirements for a solution.
 > This is off the top of my head.  I am not up to speed on shim6; they
 > may actually have requirements written out.
 >
 > 1) You want to have a efficient mechanism for authenticating that
 >    traffic is going to a valid place.
 >
 >
 > 2) You don't want attackers who were once on-path to be able to direct
 >    traffic to themselves.
 >
 > 3) You don't want off-path attackers to be able to direct traffic to
 >    themselves at all.
 >
 > 4) You don't want on-path attackers to be able to influence traffic
 >    such that it goes to them and not the original destination.
 >    I.E. if I'm on the path and also have some tunnel address you
 >    woludn't see I should not be able to redirect your traffic to my
 >    tunnel and thus capture it.
 >
 > the requirement for efficient probably rules out DH and any public-key
 > key agreement algorithm.  The requirement for deployable rules out
 > anything that assumes preconfiguration.

I don't think I agree with this assumption. A single digital
signature that's checked every time you re-home seems quite
eminently practical.

-Ekr
_______________________________________________
From: Jari Arkko <[email-masked]>

Forgot to say one thing that I wanted to say...

>The possibilities that come to my mind are
>
>  - HBAs
>  - CGAs
>  - BTNS
>
>SHIM6 is taking the approach which uses HBAs or optionally
>CGAs.

While the use of CGAs (or something BTNS+MOBIKE derived)
would be more general, I don't actually see any specific
problems in the HBA use, at least not compared to CGAs,
assuming the algorithms can be updated. HBA does not
have any less bits available than CGA, and while the technique
is very simple, it still binds the addresses together, which
was the purpose for this particular function.

Of course, we may still discuss whether we believe dynamic
addresses are frequent enough to make non-static
solutions better, or whether we want one mechanism instead
of two, etc.

--Jari

---------------------------------------------

From: Eric Rescorla <[email-masked]>

Jari Arkko <[email-masked]> writes:

 > Forgot to say one thing that I wanted to say...
 >
 >> The possibilities that come to my mind are
 >>
 >>  - HBAs
 >>  - CGAs
 >>  - BTNS
 >>
 >> SHIM6 is taking the approach which uses HBAs or optionally
 >> CGAs.
 >
 > While the use of CGAs (or something BTNS+MOBIKE derived)
 > would be more general, I don't actually see any specific
 > problems in the HBA use, at least not compared to CGAs,
 > assuming the algorithms can be updated. HBA does not
 > have any less bits available than CGA, and while the technique
 > is very simple, it still binds the addresses together, which
 > was the purpose for this particular function.

Well, I think I disagree here on philosophical grounds.
I prefer to avoid inventing new mechanisms--especially ones
of new styles--when that can be avoided. The standard primitives
we have for integrity are MACs with shared keys and digital
signatures with known public keys. Why invent something new.

-Ekr

----------------------------------------

From: Jari Arkko <[email-masked]>

Eric Rescorla wrote:

>>While the use of CGAs (or something BTNS+MOBIKE derived)
>>would be more general, I don't actually see any specific
>>problems in the HBA use, at least not compared to CGAs,
>>assuming the algorithms can be updated. HBA does not
>>have any less bits available than CGA, and while the technique
>>is very simple, it still binds the addresses together, which
>>was the purpose for this particular function.
>>
>
>Well, I think I disagree here on philosophical grounds.
>I prefer to avoid inventing new mechanisms--especially ones
>of new styles--when that can be avoided. The standard primitives
>we have for integrity are MACs with shared keys and digital
>signatures with known public keys. Why invent something new.
>
Actually, we may be in agreement here. I was
just pointing out that I don't see any specific
problem in this mechanism wrt. the desired
function. But I still agree with your philosophical
principle.

--Jari

_______________________________________________

Delivery-date: Tue, 25 Apr 2006 11:35:38 +0000
Cc:  <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Tue, 25 Apr 2006 14:35:27 +0300
To:  <[email-masked]>

Hi John,

about this particular point...

El 25/04/2006, a las 14:20, <[email-masked]> escribió:

>
>    This draft defines the mechanism and protocol to achieve both 
> failure
>    detection and locator pair exploration.  This protocol is called
>    REAchability Protocol (REAP).  It designed to be carried within the
>    SHIM6 protocol, but may also be used in other contexts.
>
> I think we should drop the '... may be used in other contexts.' as this
> seems
> outside of the scope of SHIM6. I don't think that SHIM6 should work on 
> a
> general
> purpose failure detection & path exploration protocol.
>
>

I think that there are several scenarios where there seems to be the 
need for having a protocol for detecting failures and exploring 
alternative paths. For instance, in mobile IP, there is no way to 
determine if the current CoA is working and explore alternative coas if 
a failure is detected. Similar thing happens in HIP for instance.

So, my take on this is that perhaps it would be good if the failure 
detection and alternative path exploration protocols defined by shim6 
could be reused in such scenarios (of course if this does not implies 
giving up functionality, but i don't think this is the case)

I mean, if we can define a single protocol that can be used in multiple 
scenarios that need the same functionality i think it makes sense....

Regards, marcelo

Delivery-date: Tue, 25 Apr 2006 11:21:38 +0000
Content-class: urn:content-classes:message
Subject: review of draft-ietf-shim6-failure-detection-03.txt
Date: Tue, 25 Apr 2006 14:20:48 +0300
From: <[email-masked]>
To: <[email-masked]>

Hi all,

Review of
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-0
3.txt

Here is my 2nd attempt at reviewing this document.  First one
mysteriously vanished. This has started getting long, so I will send it
in multiple parts.

Summary: I think that this document needs more work.

Small general request.  When making references, could you at least say
what the reference is?
For example:

   ... Techniques outside the scope of this
   document are used for this, for further information see [18].

I hate having to scroll to the reference section to see what you are
referencing.  At least
tell the protocl that you are refering, so I can see immediately if this
is something I am
already familiar with.

1) Abstract says:

   This document defines a mechanism for the detection of communication
   failures between two communicating hosts at IP layer, and an
   exploration protocol for switching to another pair of interfaces
   and/or addresses between the same hosts if a working pair can be
   found.  

Is this meant as a full-fledged, stand-alone protocol, or is it a
protocol in a Neighbor Discovery
sense?  This confused me; I think I'd prefer if it was the latter, and
was bound to the SHIM6
base protocol.  I'd suggest fixing the language so that people don't
assume it is a stand-alone
protocol.

   The draft also discusses the roles of a multihoming protocol
   versus network attachment functions at IP and link layers.

2) Intro says:

   This draft defines the mechanism and protocol to achieve both failure
   detection and locator pair exploration.  This protocol is called
   REAchability Protocol (REAP).  It designed to be carried within the
   SHIM6 protocol, but may also be used in other contexts.

I think we should drop the '... may be used in other contexts.' as this
seems
outside of the scope of SHIM6. I don't think that SHIM6 should work on a
general
purpose failure detection & path exploration protocol.  

   ...  We assume that there are other, higher
   level identifiers such as CGA public keys or HBA bindings that tie
   the different locators used by a node together [17].

Do we need to care about higher level identifiers for REAP?  My guess is
that
is something that should really matter for REAP, so that suggesting CGA
or HBA
would be something of relelvance for REAP is misleading.

3) Section 3:

   In SCTP [10], the addresses of the endpoints are learned in the
   connection setup phase either through listing them explicitly or via
   giving a DNS name that points to them.  

I'd just suggest that you say 

   In SCTP [10] transport addresses (IP address and port pairs) are
exchanged
   during SCTP Association (i.e. - connection) setup phase.

I don't think any implementations are using DNS at the moment for this.

This paragraph:

   SCTP does not define how local knowledge (such as information learned
   from the link layer) should be used.  SCTP also has no mechanism to
   deal with dynamic changes to the set of available addresses, although
   mechanisms for that are being developed [20].

Should be corrected to:

   SCTP does not define how local knowledge (such as information learned
   from the link layer) should be used.  SCTP currentlyl has a mechanism
to
   deal with dynamic changes to the set of available addresses under 
   development [20].

because I know of several implementations already supporting this.  It
is just
that the IETF hasn't signed off on it.

I also wonder if a blanket statement along the lines of "Many protocols,
both
standardized in the IETF and outside of the IETF make use of keep-alives
to
trVack the live-ness of a connection or session."  Also, you might want
to consider
RSVP also, as RSVP does track path conditions at the raw IP level.  I
can supply
text if needed.

4) Generally, I could quibble with some text in section 4 - if the
authors feel
quibbling is valuable, I could send text.  Some parts could benefit from
a re-write.

Section 4.4:

   IP-layer solutions need to avoid sending packets concurrently over
   multiple paths; TCP behaves rather poorly in such circumstances.  For
   this reason it is necessary to choose a particular pair of addresses
   as the current address pair which is used until problems occur, at
   least for the same session.

I'd say that TCP (and SCTP & TCP-friendly) congestion control is based
upon a notion of 
a single path. Congestion variables are calculated on a per-path basis.
Of course,
routing can introduce path changes, so TCP congestion control has
mechanisms to cope,
but frequent changes will cause problems.  There is on-going work in
this area,
TCP Quickstart for example, and some TCP extensions, but I think that
you'd rather
point out that congestion control generally performs poorly over
multiple paths
- or even that calculating congestion control over multible paths is a
research area.

5) Section 5.1:

I found this description a bit odd:

   This process consists of three tasks.  First, it is necessary to
   track local information from lower and upper layers.  For instance,
   when link layer informs that we have no connection then we know there
   is a failure.  Nodes SHOULD employ techniques listed in Section 4.1
   and Section 4.2 to be aware of the local situation.

   Similarly, it is necessary to track remote address information from
   the peer.  For instance, the peer may inform that its currently used
   address is no longer in use.  Techniques outside the scope of this
   document are used for this, for further information see [18].

You are talking about Failure Detection consisting of 3 tasks:
1) Tracking local information
2) Tracking remote peer status
3) Verifying reachability 

However, you state that the 2nd task is outside of the scope of this
document, which
seems confusing

I'd suggest a re-write along the lines of:

    Failure detection consists of three parts: tracking local
information, tracking
    remote peer status, and finally verifying reachability.  Tracking
local information
    consists of using local information such as link layer failure in
order to
    provide input into the failure detection process. Nodes SHOULD
employ techniques 
    listed in Section 4.1 and Section 4.2 to be track the local
situation.
    It is necessary to track remote address information from
    the peer.  For instance, if the peer's currently used
    address is no longer in use, mechanism to relay that information may
be 
    useful.  Techniques defined in the SHIM6 base protocal[18] can be
used.
 
Continued in the next mail (sent later today or tomorrow AM).

John

Delivery-date: Tue, 25 Apr 2006 07:04:17 +0000
From: "Per Heldal" <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>
Subject: Re: Shim6 proxies
Date: Tue, 25 Apr 2006 09:03:23 +0200

[receipient-list trimmed]
On Mon, 24 Apr 2006 19:04:34 -0400 (EDT), "Jason Schiller
[snip]
> Agreed.  To put it another way, if shim6 is not useful to largish
> enterprise customers and content providers, then they are not likely to
> turn it on, especially if it add complexity like policy routing or
> holding
> lots of state on content servers.  So unless you only want shim6 to be
> useful as a peer-to-peer technology for consumner customers figure out
> how
> to eaither add value to the business enterprise customers and content
> providers, or at least make it non-invasive to them as Scott is
> attempting.

Does anybody really believe that shim6 as described in current drafts is
the final product? Isn't that like IPv<anything> without dynamic routing
protocols or TCP without SLB-products just to mention a couple examples?
Remember how hard a sell IPv4 was up against IPX in the late 80s, early
90s, for very similar reasons?

At this stage we are, as with any technology development, uncovering
functional requirements to make it work in the real world. Hence
operational concerns are very welcome. It is too early to dismiss shim6.
Let's at least wait a few years until there are a few implementations
and some practical experience before we do so.

Guess it boils down to a choice of looking at such issues as
"problems" or "challenges".

//per
-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Tue, 25 Apr 2006 06:59:19 +0000
Cc: Per Heldal <[email-masked]>, Scott Leibrand <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Tue, 25 Apr 2006 09:58:34 +0300
To: "Jason Schiller ([email-masked])" <[email-masked]>

El 25/04/2006, a las 2:04, Jason Schiller ([email-masked]) escribió:

> On Thu, 20 Apr 2006, Scott Leibrand wrote:
>
>> Date: Thu, 20 Apr 2006 09:58:58 -0400 (EDT)
>> From: Scott Leibrand <[email-masked]>
>> To: marcelo bagnulo braun <[email-masked]>
>> Cc: Per Heldal <[email-masked]>, shim6-wg <[email-masked]>
>> Subject: Re: Shim6 proxies
>>
>> On 04/20/06 at 4:02pm +0300, marcelo bagnulo braun 
>> <[email-masked]> wrote:
>>
>>> you can still make source address based routing work in multiple hops
>>> or you can use a mesh of tunnels to allow exit routers to forward the
>>> packet to the proper exit router and so on...
>>
>> If this is a requirement to implement shim6, it will not happen.  It
>> doesn't scale, and is way too complicated to manage.  Either we find 
>> a way
>> to automate source routing by IGPs, or we give up on letting hosts 
>> control
>> its egress in networks with more than one broadcast domain.
>
> I agree with Scott.
>
> Source routing is expensive.
>
> 1. Get the source to put the "right" source address in the packet
> (e.g. it understands the IGP metrics or there is some routing oracle 
> that
> pushes enterprise wide source address preferences)
>
> OR
>
> 2. Have the egrees router re-write it on exit.
>

yes these two options have been considered and imho they are useful, 
but only in some scenarios

option number one above is good but you need to upgrade the host within 
the multihomed site. that is ok, but you would be breaking connectivity 
for legacy nodes (i.e. nodes that do not have this mechanism).

option number two provides even additional features, as some TE 
features, but it imposes even more requieremetns, since both the 
internal and the external party need to support the full shim6 protocol 
and have shim6 state

So, both of these options are ok and we may go for them , but we also 
need something else

I mean, the problem with ingress filtering is that if you have a single 
homed site with regular IPv6 nodes (no shim6/multihoming mechanisms) 
and then the site becomes multihomed, then these nodes will experience 
connectivity problems because ingress filtering (even if there is no 
failure!). So actually these nodes will ontain a worse service because 
of multihoming.

So, IMHO we need mechanisms that when a site becomes multihomed, so 
that legacy nodes without multihoming support can obtain at least 
similar service that the one they had when the site was single homed. 
(this means that will not loose packets if there is no failure)

This AFICT can only be achieved with some form of source address based 
routing in some of its forms. I agree that this may only be a 
transition tool and that more stable solutions may be required in the 
long term as the ones that you mention above, but imho something in 
those lines is needed at least to enable multihoming at the begining. 
Please note that a transitory solution based in mesh of tunnels between 
the site exit routers could be enougj to restore connectivity

makes sense?

>
>>
>>> but, i guess that as the site grows, such approaches may collide with
>>> other requirements
>>
>> I don't think it requires any growth to get such collision.  I'll put 
>> it
>> even more bluntly: almost anyone with enough routers to have an IGP 
>> and
>> run BGP *will not* want to multihome with shim6 as currently 
>> specified.
>> They may be fine with enabling shim6 on their hosts so they can talk 
>> with
>> multihomed hosts at smaller sites, but for their own multihoming such
>> sites will want to use traditional BGP techniques.
>>
>> As I've said before, I think the shim6 design needs to recognize that 
>> it
>> will not be the One and Only method for multihoming, and therefore it
>> needs to be designed to ensure that hosts that don't use shim6 for
>> multihoming can still interoperate with multihomed hosts and small 
>> sites
>> that do want to use shim6.
>
> Agreed.  To put it another way, if shim6 is not useful to largish
> enterprise customers and content providers, then they are not likely to
> turn it on, especially if it add complexity like policy routing

please note that source address based routing is only required in the 
site that is mutlihomed using the shim6 technique (i mean if you have a 
big content server located in a site that is using PI-BGP based 
multihomed and it is communicating with small multihomed site that is 
using shim6 to support multihoming, only the small site will need to do 
source address based routing in this case) so no additional burden is 
putted in the big site routing system because of the source address 
based routing used by the site using shim6

> or holding
> lots of state on content servers.

yes but this discussion wasn't actually finished in the list...

We still not have a clear picture about what the state required by 
shim6 suppose to big servers, compared to the state required by tcp for 
instance...

see Erik's mail on this issue

So, i do agree we need to make the solution attractive for big servers, 
but imho we need to quantify what this means...

Regards, marcelo

>   So unless you only want shim6 to be
> useful as a peer-to-peer technology for consumner customers figure out 
> how
> to eaither add value to the business enterprise customers and content
> providers, or at least make it non-invasive to them as Scott is
> attempting.
>
> ___Jason
>
>>
>> -Scott
>>
>

Delivery-date: Mon, 24 Apr 2006 23:05:55 +0000
Date: Mon, 24 Apr 2006 19:04:34 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: Shim6 proxies
To: Scott Leibrand <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, Per Heldal <[email-masked]>, shim6-wg <[email-masked]>

On Thu, 20 Apr 2006, Scott Leibrand wrote:

> Date: Thu, 20 Apr 2006 09:58:58 -0400 (EDT)
> From: Scott Leibrand <[email-masked]>
> To: marcelo bagnulo braun <[email-masked]>
> Cc: Per Heldal <[email-masked]>, shim6-wg <[email-masked]>
> Subject: Re: Shim6 proxies
> 
> On 04/20/06 at 4:02pm +0300, marcelo bagnulo braun <[email-masked]> wrote:
> 
> > you can still make source address based routing work in multiple hops
> > or you can use a mesh of tunnels to allow exit routers to forward the
> > packet to the proper exit router and so on...
> 
> If this is a requirement to implement shim6, it will not happen.  It
> doesn't scale, and is way too complicated to manage.  Either we find a way
> to automate source routing by IGPs, or we give up on letting hosts control
> its egress in networks with more than one broadcast domain.

I agree with Scott.

Source routing is expensive.  

1. Get the source to put the "right" source address in the packet
(e.g. it understands the IGP metrics or there is some routing oracle that
pushes enterprise wide source address preferences)    

OR 

2. Have the egrees router re-write it on exit.

> 
> > but, i guess that as the site grows, such approaches may collide with
> > other requirements
> 
> I don't think it requires any growth to get such collision.  I'll put it
> even more bluntly: almost anyone with enough routers to have an IGP and
> run BGP *will not* want to multihome with shim6 as currently specified.
> They may be fine with enabling shim6 on their hosts so they can talk with
> multihomed hosts at smaller sites, but for their own multihoming such
> sites will want to use traditional BGP techniques.
> 
> As I've said before, I think the shim6 design needs to recognize that it
> will not be the One and Only method for multihoming, and therefore it
> needs to be designed to ensure that hosts that don't use shim6 for
> multihoming can still interoperate with multihomed hosts and small sites
> that do want to use shim6.

Agreed.  To put it another way, if shim6 is not useful to largish
enterprise customers and content providers, then they are not likely to
turn it on, especially if it add complexity like policy routing or holding
lots of state on content servers.  So unless you only want shim6 to be
useful as a peer-to-peer technology for consumner customers figure out how
to eaither add value to the business enterprise customers and content
providers, or at least make it non-invasive to them as Scott is
attempting.

___Jason

> 
> -Scott
> 

Delivery-date: Thu, 20 Apr 2006 14:35:44 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Thu, 20 Apr 2006 17:08:33 +0300
To: Scott Leibrand <[email-masked]>

El 20/04/2006, a las 16:58, Scott Leibrand escribió:

> On 04/20/06 at 4:02pm +0300, marcelo bagnulo braun 
> <[email-masked]> wrote:
>
>> you can still make source address based routing work in multiple hops
>> or you can use a mesh of tunnels to allow exit routers to forward the
>> packet to the proper exit router and so on...
>
> If this is a requirement to implement shim6, it will not happen.  It
> doesn't scale, and is way too complicated to manage.  Either we find a 
> way
> to automate source routing by IGPs, or we give up on letting hosts 
> control
> its egress in networks with more than one broadcast domain.
>
>> but, i guess that as the site grows, such approaches may collide with
>> other requirements
>
> I don't think it requires any growth to get such collision.  I'll put 
> it
> even more bluntly: almost anyone with enough routers to have an IGP and
> run BGP *will not* want to multihome with shim6 as currently specified.
> They may be fine with enabling shim6 on their hosts so they can talk 
> with
> multihomed hosts at smaller sites, but for their own multihoming such
> sites will want to use traditional BGP techniques.
>
> As I've said before, I think the shim6 design needs to recognize that 
> it
> will not be the One and Only method for multihoming, and therefore it
> needs to be designed to ensure that hosts that don't use shim6 for
> multihoming can still interoperate with multihomed hosts and small 
> sites
> that do want to use shim6.
>

I am not sure why do you think this is not the case with this 
particular aspect...

I mean a big site that is multihoming using bgp will not need to do 
source address based routing of course, not even in the case that it is 
communicating with a smallish site that is using the shim and that it 
does source address based routing...

regards, marcelo

> -Scott
>

Delivery-date: Thu, 20 Apr 2006 14:18:01 +0000
Date: Thu, 20 Apr 2006 10:17:46 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: Shim6 proxies

On 04/20/06 at 5:08pm +0300, marcelo bagnulo braun <[email-masked]> wrote:

> El 20/04/2006, a las 16:58, Scott Leibrand escribió:
>
> > As I've said before, I think the shim6 design needs to recognize that
> > it will not be the One and Only method for multihoming, and therefore
> > it needs to be designed to ensure that hosts that don't use shim6 for
> > multihoming can still interoperate with multihomed hosts and small
> > sites that do want to use shim6.
>
> I am not sure why do you think this is not the case with this
> particular aspect...

To some degree it is, I'm just worried that the "everyone will want to
shim6" assumption is clouding our vision when it comes to minimizing the
burden on hosts that don't use shim6 for multihoming.

> I mean a big site that is multihoming using bgp will not need to do
> source address based routing of course, not even in the case that it is
> communicating with a smallish site that is using the shim and that it
> does source address based routing...

Right.  I'm referring to the discussion around "how much state is required
on busy servers", and "how much of that state can be safely discarded".
An important design goal IMO needs to be to make sure we don't require any
more resources than absolutely necessary at the non-multihomed end to make
shim6 work.

Perhaps another way to look at it is considering requirements for
"shim6-aware" hosts, which wouldn't multihome with shim6, but would talk
shim6 to multihomed correspondents.

An alternative, of course, is going back to the original topic of this
thread, which is designing the protocol to allow offloading of the shim6
work and state-tracking to an external proxy.  This is also something I
think will be important in getting enough content providers "shim6-aware"
to make shim6 deployment useful for multihomed hosts and small sites.

-Scott

Delivery-date: Thu, 20 Apr 2006 13:59:55 +0000
Date: Thu, 20 Apr 2006 09:58:58 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Per Heldal <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Shim6 proxies

On 04/20/06 at 4:02pm +0300, marcelo bagnulo braun <[email-masked]> wrote:

> you can still make source address based routing work in multiple hops
> or you can use a mesh of tunnels to allow exit routers to forward the
> packet to the proper exit router and so on...

If this is a requirement to implement shim6, it will not happen.  It
doesn't scale, and is way too complicated to manage.  Either we find a way
to automate source routing by IGPs, or we give up on letting hosts control
its egress in networks with more than one broadcast domain.

> but, i guess that as the site grows, such approaches may collide with
> other requirements

I don't think it requires any growth to get such collision.  I'll put it
even more bluntly: almost anyone with enough routers to have an IGP and
run BGP *will not* want to multihome with shim6 as currently specified.
They may be fine with enabling shim6 on their hosts so they can talk with
multihomed hosts at smaller sites, but for their own multihoming such
sites will want to use traditional BGP techniques.

As I've said before, I think the shim6 design needs to recognize that it
will not be the One and Only method for multihoming, and therefore it
needs to be designed to ensure that hosts that don't use shim6 for
multihoming can still interoperate with multihomed hosts and small sites
that do want to use shim6.

-Scott

Delivery-date: Thu, 20 Apr 2006 13:02:39 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Thu, 20 Apr 2006 16:02:30 +0300
To: "Per Heldal" <[email-masked]>

El 20/04/2006, a las 15:55, Per Heldal escribió:

> On Thu, 20 Apr 2006 13:54:59 +0200, "Brian E Carpenter"
> <[email-masked]> said:
>> Actually, the sending host could theoretically use a different default
>> gateway for each different source address.
>
> That should be the default behavior as RPF should be applied by each
> transit provider in a shim environment. We don't want to endorse
> routing-schemes in v6 which are wide open to spoofing.
>
>>                                     That could be used as a back door
>> method
>> for choice of exit router, without needing to touch router behavior.
>
> While this is relatively easy when you've got a single subnet connected
> to multiple providers, it'll be a challenge to make such routing work 
> in
> a complex network where there may be many hops between the shim-host 
> and
> the egress router. Egress-routers connecting to different providers may
> also be several hops apart. It's not impossible, but some may see this
> as
> a reason to restrict shim6 to smallish sites.
>

you can still make source address based routing work in multiple hops 
or you can use a mesh of tunnels to allow exit routers to forward the 
packet to the proper exit router and so on...

but, i guess that as the site grows, such approaches may collide with 
other requirements

regards, marcelo

> //per
> -- 
>   Per Heldal
>   http://heldal.eml.cc/
>
>

Delivery-date: Thu, 20 Apr 2006 12:56:15 +0000
From: "Per Heldal" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: [email-masked]
Subject: Re: Shim6 proxies
Date: Thu, 20 Apr 2006 14:55:14 +0200

On Thu, 20 Apr 2006 13:54:59 +0200, "Brian E Carpenter"
<[email-masked]> said:
> Actually, the sending host could theoretically use a different default
> gateway for each different source address. 

That should be the default behavior as RPF should be applied by each
transit provider in a shim environment. We don't want to endorse
routing-schemes in v6 which are wide open to spoofing. 

>                                     That could be used as a back door
> method
> for choice of exit router, without needing to touch router behavior.

While this is relatively easy when you've got a single subnet connected
to multiple providers, it'll be a challenge to make such routing work in
a complex network where there may be many hops between the shim-host and
the egress router. Egress-routers connecting to different providers may
also be several hops apart. It's not impossible, but some may see this
as
a reason to restrict shim6 to smallish sites.

//per
-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Thu, 20 Apr 2006 12:13:56 +0000
Date: Thu, 20 Apr 2006 08:13:37 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: What's our target audience? (Was: Re: Shim6 proxies)

On 04/20/06 at 1:54pm +0200, Brian E Carpenter <[email-masked]> wrote:

> Scott Leibrand wrote:
> ...
> >>If you don't have source address rewriting, and we assume that ingress
> >>filters are in place (which seems the by default assumption) then the
> >>source address selection actually determines the exit path form the
> >>multihomed site.
> >
> > Not in today's networks.  Currently routers route on destination address,
> > not source address, so the destination address selection determines which
> > route is used to route the packets, which in turn determines which source
> > address you have to use if you want your packets to get out.
>
> Actually, the sending host could theoretically use a different default gateway
> for each different source address. That could be used as a back door method
> for choice of exit router, without needing to touch router behaviour.

True, for a small network, where all hosts are on the same LAN as the exit
routers.  I was referring to a larger network with an IGP.

This seems to me like yet another way that shim6 is designed for small
sites, and is somewhat less suitable for larger ones.  This isn't
necessarily a bad thing, as IMO host-based multihoming makes less and less
sense the larger your site gets, but it seems to be a factor a lot of
people don't want to accept.

If we target shim6 at small-site multihoming, for networks that can't do
BGP-based multihoming today (or would prefer not to for cost), I think we
have a better shot at getting something actually deployed.  If networks
like Igor's and Patrick's aren't going to benefit from shim6 without
significant additional state in their servers, they're going to stick with
BGP multihoming.  If we recognize that, and work to make sure that his
servers can talk shim6 to multihomed clients with minimal overhead, we'll
be less likely to get caught in the catch-22 of being unable to get
traction because one end isn't interested in deploying shim6.

-Scott

Delivery-date: Thu, 20 Apr 2006 11:55:23 +0000
Date: Thu, 20 Apr 2006 13:54:59 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Scott Leibrand <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: Shim6 proxies

Scott Leibrand wrote:
...
>>If you don't have source address rewriting, and we assume that ingress
>>filters are in place (which seems the by default assumption) then the
>>source address selection actually determines the exit path form the
>>multihomed site.
> 
> 
> Not in today's networks.  Currently routers route on destination address,
> not source address, so the destination address selection determines which
> route is used to route the packets, which in turn determines which source
> address you have to use if you want your packets to get out.

Actually, the sending host could theoretically use a different default gateway
for each different source address. That could be used as a back door method
for choice of exit router, without needing to touch router behaviour.

btw, draft-huitema-shim6-ingress-filtering-00 talks about this problem.

    Brian

Delivery-date: Thu, 20 Apr 2006 11:40:53 +0000
Date: Thu, 20 Apr 2006 13:39:20 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: API for SHIM

BTW, I would expect connect-by-name to fall back to legacy
IP if attempts to connect via IPv6 fail.

(And yes, that does show that connect-by-name is not
strictly linked to shim6.)

     Brian

Delivery-date: Wed, 19 Apr 2006 13:16:09 +0000
Cc: Dana Blair <[email-masked]>, [email-masked], Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, "Jason Schiller ([email-masked])" <[email-masked]>
From: Dana Blair <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Wed, 19 Apr 2006 09:14:59 -0400
To: Geoff Huston <[email-masked]>

On Apr 13, 2006, at 8:31 PM, Geoff Huston wrote:

> SHIM6 has been chartered by the IESG to work on an identified solution 
> mechanism for site multi-homing in IPv6 that does not entail placing 
> further burden on the global routing system.

Does the charter imply that a new protocol is needed ?

What if there were an existing set of protocols that work in IPv4 for 
non-BGP multihoming that allowed some TE and did
not place a "further burden" on the global routing system ? What if 
these same protocols could be used in IPv6 ?

Careful integration of NAT and DNS across multiple ISP connections 
enables some TE for non-BGP multi-homed sites without
host cooperation.

With host cooperation (both client and server) using SCTP or HIP, even 
better control of the Internet path
can be achieved including mobility.

NAT, DNS, SCTP, or HIP can work with IPv4 or IPv6.

I don't see a need for a new protocol

thanks,
Dana

>
> The solution path is one that I believe has considerable longer term 
> positive implications to the IP architecture in that it is an approach 
> that allows a session communication to be established in a 
> conventional manner and then create a further association on an 
> end-to-end basis that allows, in a relatively secure fashion, the 
> address locators to shift within the session without incurring the 
> overhead of creating additional application or transport level 
> associations, without adding to the cost of the overall network by 
> calling for the creation of a distribution system of yet another 
> unique token .
>
> SHIM6 will continue its chartered work, of course, and is making good 
> progress with the initial specification.
>
> The issues of scaling the routing system, and the associated 
> consideration of working with the inter-domain routing system to 
> improve its robustness and security also continue to be an impetus for 
> work in this space.
>
> Personally, considering the critical consideration of scaling the IPv6 
> technology to meet the needs of a truly massively populated network in 
> the fullness of time, I feel entirely comfortable in seeing us work on 
> this scaling issue using a number of approaches at this point in time. 
> Therefore I'm of the personal view that a call to stop working on 
> SHIM6 is somewhat ill-advised right now.
>
> kind regards,
>
>    Geoff
>

Delivery-date: Tue, 18 Apr 2006 12:39:10 +0000
Date: Tue, 18 Apr 2006 15:38:02 +0300
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: API for SHIM
Cc: shim6-wg <[email-masked]>

Hi Marcelo,

please find my replies inline.

On Tue, 18 Apr 2006 13:33:34 +0300
marcelo bagnulo braun <[email-masked]> wrote:

> 
> El 12/04/2006, a las 18:01, Shinta Sugimoto escribis:
> 
> ...
> >> Right, but it is also the case that the connect by name functionality
> >> can be used without the shim and it is really useful in that case too.
> >> I mean first of all, it is important to note that in order to make  
> >> this
> >> work we don't need the shim. This is so, because at the moment that
> >> connect by name is performed , the ulid for that communication is  
> >> being
> >> determined, and it is possible to select one that is working since the
> >> application has only specified the name of the target.
> >> So, for this communication there is no real need to have a locator  
> >> that
> >> differ from the ulid used for the communication, it is just enough to
> >> select the ulid/locator in a smart fashion, so that  a working address
> >> is selected. So no need to perform the shim translation between ulid
> >> and locators in this case (Which is the main function of the shim)
> >
> > Yes, I understand your statement above.  connect_by_name() is a kind of
> > wrapper to connect() system call in a sense that it only requires app
> > to provide hostname rather than the IP address.  Then the library would
> > take care of name resolution and session establishment for each
> > resolved address.  As you pointed out, SHIM6 is not required to make
> > this work.  What I want to point out is that connect_by_name() might
> > be able to coordinate with SHIM6 REAP mechanism.
> >
> I am not sure if i am following you here, but i would think it this way:
> 
> suppose that the app performs a connect-by-name call to www.foo.com
> the resolver returns 3 addresses
> 
> Now, i guess the first interaction with the shim6 may be to find out if  
> there is an established context with one of these target addresses with  
> any of the local addresses available. If there is, it may be worthy to  
> preffer this address and initiate the communication using it, rather  
> than the other addresses for which there is no establihsed shim6  
> context. (this would be a first inter

Yes, this makes sense.

> 
> If none of them has an established context, then i guess we could have  
> two options:
> - one would be to use multiple TCP SYNs packets in parallel (this  
> option is nice because does not require shim support from the other  
> end)
> - the other one would be to  use the shim6 protocol to establish a  
> context and once the context is up, then initiate the communication.

Ok.

> >>
> >> IMHO this is very good because the connect by shim funtiobality can be
> >> used even when the peer does no supports the shim and it would allow  
> >> to
> >> establish new communications in the case of a failure in the  
> >> multihomed
> >> site.
> >
> > Agree.
> >
> >>
> >> Of course, if we don't use the shim we will need to use other than  
> >> shim
> >> messages to figure out if the address pair is working. however,
> >> considering that this is connect by name, probing with TCP syns seems
> >> the natural options and i don't see any drawback, do you?
> >
> > No.  I am not saying that probing by TCP SYNs should be replaced by
> > SHIM6 probe message.  I am saying that unnecessary attempt of sending
> > TCP SYNs to the un-working locator pairs *can* be avoided if the
> > SHIM6 REAP state indicates that the locator pair is supposedly
> > unreachable.
> 
> were you thinking about something in the lines that i described above  
> or something else?

Yes, mostly similar to the one you described above (the first bullet about
simultaneous TCP SYNs).  In a case there is already established ULID-pair
context with the peer (and associated REAP status with locator pairs),
that can be taken into account for establishing the TCP connection.

> 
> >
> ....
> >>>> - Forking related options. In particular, the
> >>>>    application should be able to request the creation
> >>>>    of a Forked Instance for a context, and should be
> >>>>    able to set the preferences for that forked instance,
> >>>>    the same as a regular context.
> >>>
> >>> This is one of the main issues of API.
> >>> I understand that forked context can be specifically used by
> >>> each application (process).  IMO, the question is how could
> >>> application have a reference to specific forked context.
> >>> Forked context could be identified by the FII, of course.
> >>> But it does not seem to be suitable/easy for application to use
> >>> it as a referral of locator.  So far, I think it would make
> >>> sense to allow application to specify ULID as well as
> >>> preferred locator (if any) to send/receive packet to/from
> >>> given socket.
> >>>
> >>
> >> but this could identify more than one forked contexts, right?
> >> i mean, there is nothing precluding that two forked contexts of the
> >> same original context use the same locator pair... in this case,
> >> locator pair and ulid pair does not identifies a single forked
> >> context... not sure if this is problem though....
> >
> > Yes, but what can SHIM6 API provide application then ?
> > Do you think that app should specify FII via socket API ?
> >
> 
> i am not sure.... perhaps a good way forward with this would be to  
> figure out how would an application that need this interact with the  
> shim in a reasonable way and then provide the interface to support such  
> interaction... but not sure...

Ok.

> ...
> >>>> - Interaction between RFC3484 and the shim. In this case,
> >>>>    the information available in the shim could be used to
> >>>>    influence RFC3484 selection procedure, so that
> >>>>    unreachable locators are avoided.
> >>>
> >>> I see.  And I tend to think that application may also want to
> >>> distinguish locator with its type.  In case of running SHIM6
> >>> over MIPv6, application may want to distinguish HoA and CoA
> >>> for achieving better performance (maybe by taking advantage of
> >>> SHIM6 based RO mode), for instance.
> >>
> >> but this is already built in the rfc3484 right? i mean, rfc3484  
> >> already
> >> preffers HoAs over Coas... besides, the basic SHIM over MIP scenario
> >> does not assumes that CoAs are exposed to the shim, i guess
> >
> > Yes, RFC3484 mentions about HoA and CoA.  It recommends to have higher
> > preference on HoA over CoA.  In plain Mobile IPv6 environment,
> > behavior following the recommendation would probably fulfill users
> > desire.  But in some advanced scenarios, app may prefer CoA for
> > better performance (SHIM6 based RO).  RFC3484 does not help to do this.
> >
> 
> but not as a ulid but as a locator right?

Right.

> from previous discussion with Erik, seemed that we may need a locator  
> selection algorithm that is shim6 specific, i.e. in order to select  
> locators withinh a context (as oposed to having to select initial  
> addresses which will be the ulids of the context and that are selected  
> by RFC3484 and possible extensions.)
> In the case of locator selection, i agree that we may need to change  
> the priorities.
> 
> The result is that a locator selection mechanisms different from  
> rfc3484 may be needed, because there are different priorities when  
> selecting locator pairs than when selecting ulid pairs.

Agree.
 
> I have wrote a proposal for this locator pair selection algorithm (but  
> i still haven't submitted it to the wg)
> 
> You can find it at:
> 
> http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-locator-pair- 
> selection-00.txt
> 
> in case anyone cares to comment...

Thanks, I will take a look at it.

> 
> >>>> Others??
> >>>
> >>> In addition, we would probably need a mechanism for providing
> >>> application ancillary data that are related to SHIM6 behavior.
> >>> For instance, application may want to know which locator was
> >>> *actually* used to receive/send given IP datagram.
> >>>
> >>
> >> you mean about packets sent in the past?
> >
> > No.  I am talking about the ancillary data which (extended)
> > Socket API may provide from SHIM6 perspective.  What I have in mind
> > is that application may want to know src/dst locators
> > which were actually used to deliver the packet to the host.
> > Well, it may sound contradictory to the basic concept of SHIM6
> > which is to make locator information transparent to the ULP.
> > But some application may still want to know (for some reason)
> >
> 
> yes, this is the question, what would be the motivations for this  
> feature?

Hmm, I don't persuasive answer for the question at the moment...

> I mean i am all for doing a richer api but i guess we need at least one  
> use case per feature :-)

Yes.  Let me come back if I find any good usecase.

Regards,
Shinta

Delivery-date: Tue, 18 Apr 2006 10:34:28 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: API for SHIM
Date: Tue, 18 Apr 2006 13:33:34 +0300
To: Shinta Sugimoto <[email-masked]>

El 12/04/2006, a las 18:01, Shinta Sugimoto escribió:

...
>> Right, but it is also the case that the connect by name functionality
>> can be used without the shim and it is really useful in that case too.
>> I mean first of all, it is important to note that in order to make  
>> this
>> work we don't need the shim. This is so, because at the moment that
>> connect by name is performed , the ulid for that communication is  
>> being
>> determined, and it is possible to select one that is working since the
>> application has only specified the name of the target.
>> So, for this communication there is no real need to have a locator  
>> that
>> differ from the ulid used for the communication, it is just enough to
>> select the ulid/locator in a smart fashion, so that  a working address
>> is selected. So no need to perform the shim translation between ulid
>> and locators in this case (Which is the main function of the shim)
>
> Yes, I understand your statement above.  connect_by_name() is a kind of
> wrapper to connect() system call in a sense that it only requires app
> to provide hostname rather than the IP address.  Then the library would
> take care of name resolution and session establishment for each
> resolved address.  As you pointed out, SHIM6 is not required to make
> this work.  What I want to point out is that connect_by_name() might
> be able to coordinate with SHIM6 REAP mechanism.
>
I am not sure if i am following you here, but i would think it this way:

suppose that the app performs a connect-by-name call to www.foo.com
the resolver returns 3 addresses

Now, i guess the first interaction with the shim6 may be to find out if  
there is an established context with one of these target addresses with  
any of the local addresses available. If there is, it may be worthy to  
preffer this address and initiate the communication using it, rather  
than the other addresses for which there is no establihsed shim6  
context. (this would be a first inter

If none of them has an established context, then i guess we could have  
two options:
- one would be to use multiple TCP SYNs packets in parallel (this  
option is nice because does not require shim support from the other  
end)
- the other one would be to  use the shim6 protocol to establish a  
context and once the context is up, then initiate the communication.

>>
>> IMHO this is very good because the connect by shim funtiobality can be
>> used even when the peer does no supports the shim and it would allow  
>> to
>> establish new communications in the case of a failure in the  
>> multihomed
>> site.
>
> Agree.
>
>>
>> Of course, if we don't use the shim we will need to use other than  
>> shim
>> messages to figure out if the address pair is working. however,
>> considering that this is connect by name, probing with TCP syns seems
>> the natural options and i don't see any drawback, do you?
>
> No.  I am not saying that probing by TCP SYNs should be replaced by
> SHIM6 probe message.  I am saying that unnecessary attempt of sending
> TCP SYNs to the un-working locator pairs *can* be avoided if the
> SHIM6 REAP state indicates that the locator pair is supposedly
> unreachable.

were you thinking about something in the lines that i described above  
or something else?

>
....
>>>> - Forking related options. In particular, the
>>>>    application should be able to request the creation
>>>>    of a Forked Instance for a context, and should be
>>>>    able to set the preferences for that forked instance,
>>>>    the same as a regular context.
>>>
>>> This is one of the main issues of API.
>>> I understand that forked context can be specifically used by
>>> each application (process).  IMO, the question is how could
>>> application have a reference to specific forked context.
>>> Forked context could be identified by the FII, of course.
>>> But it does not seem to be suitable/easy for application to use
>>> it as a referral of locator.  So far, I think it would make
>>> sense to allow application to specify ULID as well as
>>> preferred locator (if any) to send/receive packet to/from
>>> given socket.
>>>
>>
>> but this could identify more than one forked contexts, right?
>> i mean, there is nothing precluding that two forked contexts of the
>> same original context use the same locator pair... in this case,
>> locator pair and ulid pair does not identifies a single forked
>> context... not sure if this is problem though....
>
> Yes, but what can SHIM6 API provide application then ?
> Do you think that app should specify FII via socket API ?
>

i am not sure.... perhaps a good way forward with this would be to  
figure out how would an application that need this interact with the  
shim in a reasonable way and then provide the interface to support such  
interaction... but not sure...

...
>>>> - Interaction between RFC3484 and the shim. In this case,
>>>>    the information available in the shim could be used to
>>>>    influence RFC3484 selection procedure, so that
>>>>    unreachable locators are avoided.
>>>
>>> I see.  And I tend to think that application may also want to
>>> distinguish locator with its type.  In case of running SHIM6
>>> over MIPv6, application may want to distinguish HoA and CoA
>>> for achieving better performance (maybe by taking advantage of
>>> SHIM6 based RO mode), for instance.
>>
>> but this is already built in the rfc3484 right? i mean, rfc3484  
>> already
>> preffers HoAs over Coas... besides, the basic SHIM over MIP scenario
>> does not assumes that CoAs are exposed to the shim, i guess
>
> Yes, RFC3484 mentions about HoA and CoA.  It recommends to have higher
> preference on HoA over CoA.  In plain Mobile IPv6 environment,
> behavior following the recommendation would probably fulfill users
> desire.  But in some advanced scenarios, app may prefer CoA for
> better performance (SHIM6 based RO).  RFC3484 does not help to do this.
>

but not as a ulid but as a locator right?

from previous discussion with Erik, seemed that we may need a locator  
selection algorithm that is shim6 specific, i.e. in order to select  
locators withinh a context (as oposed to having to select initial  
addresses which will be the ulids of the context and that are selected  
by RFC3484 and possible extensions.)
In the case of locator selection, i agree that we may need to change  
the priorities.

The result is that a locator selection mechanisms different from  
rfc3484 may be needed, because there are different priorities when  
selecting locator pairs than when selecting ulid pairs.

I have wrote a proposal for this locator pair selection algorithm (but  
i still haven't submitted it to the wg)

You can find it at:

http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-locator-pair- 
selection-00.txt

in case anyone cares to comment...

>>>> Others??
>>>
>>> In addition, we would probably need a mechanism for providing
>>> application ancillary data that are related to SHIM6 behavior.
>>> For instance, application may want to know which locator was
>>> *actually* used to receive/send given IP datagram.
>>>
>>
>> you mean about packets sent in the past?
>
> No.  I am talking about the ancillary data which (extended)
> Socket API may provide from SHIM6 perspective.  What I have in mind
> is that application may want to know src/dst locators
> which were actually used to deliver the packet to the host.
> Well, it may sound contradictory to the basic concept of SHIM6
> which is to make locator information transparent to the ULP.
> But some application may still want to know (for some reason)
>

yes, this is the question, what would be the motivations for this  
feature?

I mean i am all for doing a richer api but i guess we need at least one  
use case per feature :-)

Regards, marcelo

> what is the decision made by the underlying SHIM6 layer in
> locator selection.  In the past discussions on SHIM6 & TE, it
> was suggested to allow locator rewriting at the site exit router.
> So, in SHIM6 a host may receive an IP packet on the locator
> which is not the preferred one.  But I don't have the answer for
> a question why would the application need such info ...
>
> My statement above only considers inbound packet processing.
>

>> I am not sure that the shim needs to keep the historical data of
>> locators used for any reason.... why would you require that for?
>
> see above.
>
>
> Regards,
> Shinta
>

Delivery-date: Tue, 18 Apr 2006 07:38:21 +0000
Cc: Joe Abley <[email-masked]>, [email-masked], Scott Leibrand <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 failure recovery after garbage collection
Date: Tue, 18 Apr 2006 10:37:55 +0300
To: Igor Gashinsky <[email-masked]>

Hi Igor,

El 18/04/2006, a las 4:23, Igor Gashinsky escribió:

> :: One of the more comprehensible objections to shim6 that was raised 
> at NANOG
> :: 35 was from large content providers who currently serve many 
> thousands of
> :: simultaneous clients through load balancers or other 
> content-aggregation
> :: devices (the kind of devices which switch connections to origin 
> servers
> :: without having to store any locally).
> ::
> :: I don't remember the precise number of simultaneous sessions the 
> devices were
> :: intended to be capable of serving, but it was a lot.
> ::
> :: The observation was that with the amount of (server, client) state 
> being held
> :: on those devices, adding what might be an average of (say) 2x128 
> bits + misc
> :: overhead per session might present scaling difficulties.
>
> A single WSM-6 Foundry SI450 can handle 15M sessions in the state 
> machine.
> Assuming an overhead of say, 320 bits per session * 15M sessions we 
> come
> up with approx 600MB of extra RAM added to those devices (and that's on
> the low side). Multiply out that a large content provider would have
> *hundreds* of these devices, it's not a small cost (depending on
> the vendor, that memory is not general purpose DRAM, and could be 
> *very*
> expensive). Now, that is only extra memory to do nothing but hold other
> locators.
>

i am not very familiar with this type of devices, but why do they need 
to have shim6 state on them?.... i mean, the shim state is required 
only the end point of the communication, not in any middle box, 
AFAICT...

> On the web server side, it's not uneard of for a single webserver to
> handle 10-20k active, concurrent connections, with another 20k or so
> being in various *_WAIT states. Adding an extra 40byte per session
> overhead per server is really not that bad (800kb of RAM/server),
> although I have no idea what that overhead does to the kernel queues...
>

but the shim6 context is not per connection, but per peer (more 
precisely per ULID pair).... hence the question is how many different 
ulid pairs are involved in these connections... I mean AFAIK, each 
client establishes in general quite more than one TCP connection to the 
web server to download a page...

> The thing is, those numbers are only taking into account holding
> *locators*, and when you start talking about holding onto other things
> (like, say reachability state, performance (RTT) state) the memory
> utilizations starts to increase slightly more, although still manageble
> for the servers (but is rapidly getting more and more expensive on the
> SLB's).
>  When you then start talking about now holding some sort of a TE
> state (because TE is a requirement), and you need to add the routing
> table into the equation, *now* it's gets down right nasty. 10-20Mb per
> server for shim6 overhead is minor, but add in 200+Mb of routing state,
> and it's a non-starter.

but you don't need to have the full routing table in the server...

I mean the server need to know its preferences about which 
locators-pairs it preffers

i guess you can have a very fine granulated policy but i don't think 
you will need 200.000 preferences set in the server.

Now perhaps want you need is to use the routing table information to 
decide which locator do you preffer, is that it?

In this case, i agree that having full bgp table may be useful to 
select which path to use (hence which source address to use to reach a 
certain destiantion) Morevoer, it is likely that you may need multiple 
bgp feed, one per available ISP (so that you can select the path 
through the ISP that is best)

But for this, it is possible to off load the bgp processing to a 
separate box, like the NAROS solution proposed a while back.

>
> Also, all of this conversation is only talking about memory overhead, 
> what
> about other overhead? Would the server have to do any sort of failure
> detection, and how many cycles would that consume?

that would depend on the type of traffic...
if the traffic is bidirectional (which in the TCP case, it usually is) 
and the timers are tuned, then probably there is no need to send 
keepalives, so no added traffic
but again it depends on the traffic pattern

>  Would the server have
> to do any sort of path optimization,

not sure what do you mean by this...

>  and how many cycles would that
> consume? How do I get TE state to all of my 100k+ host?

We have already exchanged some emails about this, about DHCP and so on. 
But i guess the point is:
- this is not addressed today
- however, we can try to design a mechanism that address this need that 
fullfills the requirements that you have, whether this is like a 
central server(s) that download the policy to the hosts or this is 
something like what is Erik draft about letting the routers to select 
the exit path and rewrite to source addresses, is up for discussion.

>  How many
> cycles would all the hosts need to consume if one of my peers
> bounces, and now, instead of 10-20 routers processing that, all 100k
> of my hosts have to be updated with that information?

but would all the 100k hosts will be actively  talking to the same 
peer? is that a expected scenario? i would say that in general if a 
peer bounces, then those hosts that have active communications with 
this peer will need to rehome their communication

Regards, marcelo

>  etc...
>
> -igor
>

Delivery-date: Tue, 18 Apr 2006 07:22:05 +0000
From: "Per Heldal" <[email-masked]>
To: "Igor Gashinsky" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "Scott Leibrand" <[email-masked]>, [email-masked], "Joe Abley" <[email-masked]>
Subject: Re: Shim6 failure recovery after garbage collection
Date: Tue, 18 Apr 2006 09:19:55 +0200

Igor,

Throughout your message you refer to overhead/session. Shim6 operates at
L3, so overhead must be counted per unique source-dest host (source-dest
ULID-pair). Neither does shim6 have to re-negotiate or change state for
each protocol-connection that gets established or torn down. Not saying
there is no overhead, but this makes a huge difference to the numbers.

Shim6 will, if or when it becomes available, represent an opportunity to
equipment-makers like any other new technology. That will normally lead
to the development of new products and product-families. It's premature
to dismiss a technology during research just because something is done
differently.

The biggest mistake in recent months is that shim6 has been used as an
argument in discussions of operational nature (RIR policies). Devices
generally don't run very well on vapor-ware, and thus isn't very popular
among operators ;-)  OTOH, operational concerns and feedback from the
ops-community is important to shim6 development.

//per

-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Tue, 18 Apr 2006 01:24:11 +0000
Date: Mon, 17 Apr 2006 21:23:30 -0400 (EDT)
From: Igor Gashinsky <[email-masked]>
To: Joe Abley <[email-masked]>
cc: Erik Nordmark <[email-masked]>,  Scott Leibrand <[email-masked]>, [email-masked]
Subject: Re: Shim6 failure recovery after garbage collection

:: One of the more comprehensible objections to shim6 that was raised at NANOG
:: 35 was from large content providers who currently serve many thousands of
:: simultaneous clients through load balancers or other content-aggregation
:: devices (the kind of devices which switch connections to origin servers
:: without having to store any locally).
:: 
:: I don't remember the precise number of simultaneous sessions the devices were
:: intended to be capable of serving, but it was a lot.
:: 
:: The observation was that with the amount of (server, client) state being held
:: on those devices, adding what might be an average of (say) 2x128 bits + misc
:: overhead per session might present scaling difficulties.

A single WSM-6 Foundry SI450 can handle 15M sessions in the state machine. 
Assuming an overhead of say, 320 bits per session * 15M sessions we come 
up with approx 600MB of extra RAM added to those devices (and that's on 
the low side). Multiply out that a large content provider would have 
*hundreds* of these devices, it's not a small cost (depending on 
the vendor, that memory is not general purpose DRAM, and could be *very* 
expensive). Now, that is only extra memory to do nothing but hold other 
locators.

On the web server side, it's not uneard of for a single webserver to 
handle 10-20k active, concurrent connections, with another 20k or so 
being in various *_WAIT states. Adding an extra 40byte per session 
overhead per server is really not that bad (800kb of RAM/server), 
although I have no idea what that overhead does to the kernel queues...

The thing is, those numbers are only taking into account holding 
*locators*, and when you start talking about holding onto other things 
(like, say reachability state, performance (RTT) state) the memory 
utilizations starts to increase slightly more, although still manageble 
for the servers (but is rapidly getting more and more expensive on the 
SLB's). When you then start talking about now holding some sort of a TE 
state (because TE is a requirement), and you need to add the routing 
table into the equation, *now* it's gets down right nasty. 10-20Mb per 
server for shim6 overhead is minor, but add in 200+Mb of routing state, 
and it's a non-starter.

Also, all of this conversation is only talking about memory overhead, what 
about other overhead? Would the server have to do any sort of failure 
detection, and how many cycles would that consume? Would the server have 
to do any sort of path optimization, and how many cycles would that 
consume? How do I get TE state to all of my 100k+ host? How many 
cycles would all the hosts need to consume if one of my peers 
bounces, and now, instead of 10-20 routers processing that, all 100k 
of my hosts have to be updated with that information? etc... 

-igor

Delivery-date: Tue, 18 Apr 2006 00:56:50 +0000
Cc: Scott Leibrand <[email-masked]>, shim6-wg <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: Shim6 failure recovery after garbage collection
Date: Mon, 17 Apr 2006 20:56:34 -0400
To: Erik Nordmark <[email-masked]>

On 17-Apr-2006, at 20:11, Erik Nordmark wrote:

> Joe Abley wrote:
>
>> One of the more comprehensible objections to shim6 that was raised  
>> at NANOG 35 was from large content providers who currently serve  
>> many thousands of simultaneous clients through load balancers or  
>> other content-aggregation devices (the kind of devices which  
>> switch connections to origin servers without having to store any  
>> locally).
>
> But when I watched the Nanog movie on that session, there seemed to  
> be a prevailing confusion that shim6 would setup state for every  
> TCP connection, when in fact its state is per IP address pair.

Yeah. I was referring to conversations I had afterwards in hallways,  
not to the shouting match itself.

Joe

Delivery-date: Tue, 18 Apr 2006 00:25:13 +0000
Date: Mon, 17 Apr 2006 17:25:01 -0700
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Scott Leibrand <[email-masked]>, [email-masked]
Subject: Re: Shim6 proxies

Brian E Carpenter wrote:
> Excuse front posting but these comments are quite general.
> 
> What Scott is describing is essentially full offload of the
> shim and the bottom part of the stack. We'd actually end
> up with two IP stacks - one in the host which just sends
> packets to the offload device, and a second one in the
> offload device which has a shim on top of it. I'd want to
> see a complete architecture for that including a demonstration
> that the security architecture of shim6 isn't damaged,
> and analysis of the trust model and threat model
> between the host and the offload device. But if it can be
> done, it has a very nice property - it actually offers
> a practical way to implement something that works much like
> 8+8. The offload device will be state-heavy though; it will
> need to carry state per session for every host it's supporting.

FWIW I think draft-nordmark-shim6-esd is more in the spirit of a 8+8 
implementation (as 16+16); 8+8/GSE has the property that the host that 
initiates communication has multiple destination addresses to choose 
between. Once packets start flowing in 8+8/GSE/16+16, the routers have 
the opportunity to influence the addresses by rewriting the source locator.

    Erik

Delivery-date: Tue, 18 Apr 2006 00:22:41 +0000
Date: Mon, 17 Apr 2006 17:22:20 -0700
From: Erik Nordmark <[email-masked]>
To: Scott Leibrand <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: Shim6 proxies

Scott Leibrand wrote:

> If you're going to do a full proxy, you have to go all the way IMO.  That
> means that for whatever locators the end hosts use, whether they have
> multiple locators are not, have to be assumed to be fixed for the session,
> just like ULIDs.  The shim6 proxy would then intercept all shim6 control
> traffic to that IP, and perform the shim functions on behalf of the host.
> It would have a bunch of its own locators, which would make up the locator
> set.  It could also include the ULID as one of those locators, and
> intercept traffic to that IP with shim6 headers, or I suppose it could
> treat the host's IP as a non-routable identifier for shim6 purposes and
> just use its own locators in the locator set.  Either way, the proxy would
> process all shim6-tagged traffic for the host, de-shim it as normal, and
> then pass the traffic along to the host's IP instead of passing it up to
> the ULP.

I think such a proxy could be built, but instead of relying on some 
complex DHCPv6 coordination of the address assigned to a host, it is 
much much easier to build and deploy and as IPv6 NAT + shim6 proxy.

Thus the host picks an single IPv6 address just like today (using 
stateless address autoconfig or DHCPv6) and the NAT maintains a 1-1 
mapping between those local addresses and a ULID (and HBA/CGA parameter 
set); thus the NAT doesn't need to mess with the port numbers.

The proxy then does all of shim6 on behalf of the host.

One disadvantage with this approach is that the proxy becomes a single 
point of failure for a TCP connection. But since the 1-1 mapping can be 
fixed it can be more easily shared across a pair such NATting proxies 
than today's IPv4 NATs that rewrite port numbers.
Another disadvantage is that you probably need a two-faced DNS 
(different answers for internal queries than external ones) so that 
site-internal traffic can use whatever local IPv6 addresses (ULAs?) that 
are assigned to the hosts.
A third disadvantage is that things which don't work through NAT might 
not work through such a proxy.

So I don't think such a proxy is desirable long-term, even though it can 
be valuable as part of a transition to shim6.

And as I said, the alternative that Marcelo has been talking about where 
the DHCPv6 address assignment to the host is coordinated with the shim6 
proxy is a lot more complex.

Thus asking what traffic engineering influence can be accomplished with 
a locator rewrite by the routers is still a very important question in 
my mind when it comes to the longer-term direction.

    Erik

Delivery-date: Tue, 18 Apr 2006 00:12:10 +0000
Date: Mon, 17 Apr 2006 17:11:24 -0700
From: Erik Nordmark <[email-masked]>
To: Joe Abley <[email-masked]>
CC: Scott Leibrand <[email-masked]>, [email-masked]
Subject: Re: Shim6 failure recovery after garbage collection

Joe Abley wrote:

> One of the more comprehensible objections to shim6 that was raised at 
> NANOG 35 was from large content providers who currently serve many 
> thousands of simultaneous clients through load balancers or other 
> content-aggregation devices (the kind of devices which switch 
> connections to origin servers without having to store any locally).

But when I watched the Nanog movie on that session, there seemed to be a 
prevailing confusion that shim6 would setup state for every TCP 
connection, when in fact its state is per IP address pair.

> I don't remember the precise number of simultaneous sessions the devices 
> were intended to be capable of serving, but it was a lot.

> The observation was that with the amount of (server, client) state being 
> held on those devices, adding what might be an average of (say) 2x128 
> bits + misc overhead per session might present scaling difficulties.

Sure, but each TCP connection in TIME_WAIT state (and there can be a 
large number of them for every client IP address) takes up more memory 
than that.

For active sessions then in addition to the TCP state there is also 
socket level state plus some state in the applications memory, so in 
that case the shim6 state (which is per client IP address and not per 
connection) might disappear completely in the noise.

> Perhaps Igor or Patrick could comment on likely numbers of (server, 
> client) state required (perhaps excluding sessions in TIME_WAIT) in 
> their experience -- with actual numbers, the scale of the issue might be 
> more apparent.

I think having three sets of numbers would be the most helpful:
  - number of active TCP connections (not in TIME_WAIT)
  - number of unique client IP addresses for those connections
  - number of TIME_WAIT TCP connections

I can measure how much memory is used by each one (assuming the 
application state per active connection is zero) to get some ballpark 
numbers of the impact on shim6 for every active client IP address.

    Erik

Delivery-date: Mon, 17 Apr 2006 23:26:13 +0000
Cc: Scott Leibrand <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: Shim6 failure recovery after garbage collection
Date: Mon, 17 Apr 2006 19:25:59 -0400
To: Erik Nordmark <[email-masked]>

On 17-Apr-2006, at 19:03, Erik Nordmark wrote:

> Taking a step back, why do we think that having a few bytes of  
> shim6 context on the server as a problem? A http server is likely  
> to have many TCP connections in TIME_WAIT state for every client IP  
> address, but it will have at most one shim6 context state.

One of the more comprehensible objections to shim6 that was raised at  
NANOG 35 was from large content providers who currently serve many  
thousands of simultaneous clients through load balancers or other  
content-aggregation devices (the kind of devices which switch  
connections to origin servers without having to store any locally).

I don't remember the precise number of simultaneous sessions the  
devices were intended to be capable of serving, but it was a lot.

The observation was that with the amount of (server, client) state  
being held on those devices, adding what might be an average of (say)  
2x128 bits + misc overhead per session might present scaling  
difficulties.

> And with TCP a shim6 implementation can probably discard the shim6  
> state when the last TCP socket closes (i.e. long before the  
> TIME_WAIT connections can be discarded).

I hear what you are saying.

Perhaps Igor or Patrick could comment on likely numbers of (server,  
client) state required (perhaps excluding sessions in TIME_WAIT) in  
their experience -- with actual numbers, the scale of the issue might  
be more apparent.

Joe

Delivery-date: Mon, 17 Apr 2006 23:08:45 +0000
Date: Mon, 17 Apr 2006 16:08:34 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: about draft-ietf-shim6-app-refer-00.txt

marcelo bagnulo braun wrote:
> Hi all,
> 
> I wanted to ask what happen with draft-ietf-shim6-app-refer-00.txt
> 
> I mean i can't find it anymore in the wg page listed as a wg draft
> 
> Did we drop this work from the wg?

Presumably the I-D has expired.

> I think this is a really valuable document and has provided much 
> guidance for the design of the shim solution. imho it would be useful to 
> publish it as an informational RFC

I can submit an new I-D to keep it alive, but I had no comments hence no 
updates to the document.

What does the WG want to do with this draft?

    Erik

Delivery-date: Mon, 17 Apr 2006 23:06:42 +0000
Date: Mon, 17 Apr 2006 16:06:24 -0700
From: Erik Nordmark <[email-masked]>
To: Igor Gashinsky <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

Igor Gashinsky wrote:

> [1] Those requirements, which shim6 currently fails to meet, again, are:
> 1) equal or better TE capabilities to PI multihoming in IPv4
> 	a) those capabilities controled site wide, not host-wide
> 	b) those capabilities covering all deployment scenarious that IPv4 
> 	   currently covers and people use heavily (ie inbound/outbound 
>     	   TE, transit TE, partial routes TE, peering TE, etc)
> 2) equal or better convergence around failures as IPv4 ie (1st packet 
> 	shim)
> 3) do all that without an undue burden on the server/SLB/proxy device

Igor,

have you looked at the ideas in draft-nordmark-shim6-esd-00.txt to see 
if there is something in there that would be helpful with respect to #1 
and #2 above?

   Erik

Delivery-date: Mon, 17 Apr 2006 23:04:09 +0000
Date: Mon, 17 Apr 2006 16:03:17 -0700
From: Erik Nordmark <[email-masked]>
To: Scott Leibrand <[email-masked]>
CC: [email-masked]
Subject: Re: Shim6 failure recovery after garbage collection

Scott Leibrand wrote:
> In a private discussion at IETF in Dallas, I was discussing with someone
> the impact on a content provider's server of implementing shim6.  I
> expressed the opinion that it would be nice if a heavily loaded server
> could aggressively garbage collect shim6 state after initial context
> establishment, and rely on the client to perform failure and reachability
> detection and initiate context re-establishment if a failure is detected.
> 
> If such behavior is supported by the protocol, we're much more likely to
> be able to convince potential implementors to turn on basic shim6 support
> by default, with the understanding that implementors can aggressively
> discard shim6 context state (and not initiate shim6 context negotiation)
> if the implementation doesn't have multiple locators or otherwise doesn't
> need the capabilities shim6 provides.  This would (properly, IMO) push the
> responsibility for context tracking, failure detection and reachability
> exploration to the multihomed host that stands to benefit most from shim6
> and wants to run it in the first place.

Scott,

One disadvantage of this is that there are some failures for which there 
is no recovery.
Imagine client C and server S.
C establishes a shim6 context with the server S, and sets up some TCP 
connection(s). S then discards the shim6 state.

C sends the HTTP request, and gets the TCP ACK back.
S starts sending the (possibly very large HTTP response).
Somewhere part through packets don't make it any more.

The problem is that S doesn't have any alternate locators for C.
And C will not see a problem since its TCP is happy as a clam - it 
doesn't have any unacknowledged data. Perhaps the application (if 
content-length was set) can wonder why things stalled, but having to 
push the failure recovery to every application would be undesirable.

Taking a step back, why do we think that having a few bytes of shim6 
context on the server as a problem? A http server is likely to have many 
TCP connections in TIME_WAIT state for every client IP address, but it 
will have at most one shim6 context state.
And with TCP a shim6 implementation can probably discard the shim6 state 
when the last TCP socket closes (i.e. long before the TIME_WAIT 
connections can be discarded).

Having an implementation of shim6 and running it with realistic (web) 
server workloads would help answer the question of the impact on the 
memory footprint, but from my thinking of how to implement shim6, I 
don't see it as being significant.

    Erik

Delivery-date: Mon, 17 Apr 2006 05:13:00 +0000
Content-class: urn:content-classes:message
Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Mon, 17 Apr 2006 08:12:17 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Igor,

>So, who are we trying to solve the problem for, because if the 
>answer is both, shim6 does not work, if the answer is branch 
>office, shim6 still does not work, and if the answer is the 
>DSL end-user, how many of them really want to multihome, and, 
>like Patrick said, are we trying to solve a problem that does 
>not exist? Right now, the scope is "everything", so perhaps 
>it's time to break up the problem space, and maybe have 
>different solutions for different problems?

If you are thinking about wired users, I agree, there isn't much
need for multihoming.  When you toss wireless into the mix, things
get a bit more interesting.  There are dual-mode devices already
(3G - WLAN) and WiMAX is on the horizon.  As wireless tends to have
partially overlapping coverage, but not complete coverage in all
areas (many people have terrible indoor cellular coverage, but
excellent WLAN).  Currently, users may have different wireless
providers, so the ability to multihome over different wireless
interfaces, using different service providers is a good use case,
IMO.  

John

Delivery-date: Mon, 17 Apr 2006 04:34:42 +0000
Date: Mon, 17 Apr 2006 00:33:47 -0400 (EDT)
From: Igor Gashinsky <[email-masked]>
To: Scott Leibrand <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>,  "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

On Sun, 16 Apr 2006, Scott Leibrand wrote:

:: On 04/16/06 at 10:59pm -0400, Igor Gashinsky <[email-masked]> wrote:
:: 
:: > [1] Those requirements, which shim6 currently fails to meet, again, are:
:: > 1) equal or better TE capabilities to PI multihoming in IPv4
:: > 	a) those capabilities controlled site wide, not host-wide
:: > 	b) those capabilities covering all deployment scenarios that IPv4
:: > 	   currently covers and people use heavily (ie inbound/outbound
:: >     	   TE, transit TE, partial routes TE, peering TE, etc)
:: > 2) equal or better convergence around failures as IPv4 ie (1st packet
:: > 	shim)
:: > 3) do all that without an undue burden on the server/SLB/proxy device
:: 
:: Igor (and Patrick),
:: 
:: I understand that shim6 doesn't provide a solution for content providers'
:: multihoming needs.  IMO that's one of the reasons we had to go ahead with
:: PI.  However, I wonder how you (and Patrick) would feel about continuing
:: to use PI space in IPv6, and also supporting shim6 to allow the end users
:: you're communicating with to multihome?  In my mind, the balance point
:: would be to configure your servers to not initiate shim6 capability
:: negotiation, to allow negotiation if the client initiates it, and to
:: promptly discard shim6 context after capability negotiation is complete.

Hey Scott,

The problem with this is 2-fold. First, we (still) lack TE. Whereas
right now when a multihomed user initiates a connection to my server, I 
know what the best path is to reach him (taking into account all of his 
providers, BGP gives me plenty of visibility/flexibility), and I can 
perform TE on those packets (what if I peer with one of his providers, and 
not another, or what if one of his providers costs me $X/mbps, and the 
other $10x/mbps). That is something that is completely lacking in 
shim6. The other issue is that I can not simply discard the shim6 context 
once it's initiated (a broken session is not an acceptable scenario for 
me, even for a single HTTP/1.0 GET in ipv4, why would it be acceptable in 
ipv6?), since w/o knowing both ips for the end client, if a client 
re-home occurs, my server won't know that it's the same session, and will 
reset it, so it fails the "equal or better convergence" requirement. 

Also, what makes you think that the lack of TE is acceptable to the end 
user? The way I see it, we are trying to solve 2 very distict problems: 
*client* multihoming (ie end user on dsl, who wants his cable modem to be 
his backup), and *site* multihoming (anything from a small branch office 
with 20-100 users there to a larger one with 500 users, to a server farm, 
all having a real network admins, and even minor bgp-foo) in a single 
solution, but they have 2 very different requirements. One of which, 
currently, has a valid method of multihoming (it's not uncommon for a 
business to get a single PI allocation, and slice it up among branch 
offices, so the sites essentially use PI space, or get PA space form one 
of his providers, and advertise it to both) and the other one (end user) 
does not. Solving the problem for the DSL end-user is potentialy several 
orders of magnitude easier then solving it for the branch site, since the 
end user can't do it currently, therefore has no expectations, and the 
site can, and expects to be able to do things with the same capabilities 
as in v4. 

So, who are we trying to solve the problem for, because if the answer is 
both, shim6 does not work, if the answer is branch office, shim6 still 
does not work, and if the answer is the DSL end-user, how many of them 
really want to multihome, and, like Patrick said, are we trying to solve a 
problem that does not exist? Right now, the scope is "everything", 
so perhaps it's time to break up the problem space, and maybe have 
different solutions for different problems?

Thanks,
-igor

Delivery-date: Mon, 17 Apr 2006 03:38:08 +0000
Date: Sun, 16 Apr 2006 23:36:52 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: Igor Gashinsky <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>,  "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

On 04/16/06 at 10:59pm -0400, Igor Gashinsky <[email-masked]> wrote:

> [1] Those requirements, which shim6 currently fails to meet, again, are:
> 1) equal or better TE capabilities to PI multihoming in IPv4
> 	a) those capabilities controlled site wide, not host-wide
> 	b) those capabilities covering all deployment scenarios that IPv4
> 	   currently covers and people use heavily (ie inbound/outbound
>     	   TE, transit TE, partial routes TE, peering TE, etc)
> 2) equal or better convergence around failures as IPv4 ie (1st packet
> 	shim)
> 3) do all that without an undue burden on the server/SLB/proxy device

Igor (and Patrick),

I understand that shim6 doesn't provide a solution for content providers'
multihoming needs.  IMO that's one of the reasons we had to go ahead with
PI.  However, I wonder how you (and Patrick) would feel about continuing
to use PI space in IPv6, and also supporting shim6 to allow the end users
you're communicating with to multihome?  In my mind, the balance point
would be to configure your servers to not initiate shim6 capability
negotiation, to allow negotiation if the client initiates it, and to
promptly discard shim6 context after capability negotiation is complete.

If you were to do something like that, it seems to me that you would incur
very little cost, as most multihomed clients would never even initiate
shim6 capability negotiation due to short session duration.  Those that do
would only require you incur the processing overhead to deal with those
packets: once the negotiation is complete you can safely discard the
resulting state.

The only time this type of shim6 support would require additional state
tracking on your side would be when a multihomed client experiences a
failure, initiates reachability exploration, prompts context
re-establishment, and then re-homes to a working locator pair.  This is
likely to be rare, and when it does occur the additional state is allowing
you to successfully complete a transaction that would otherwise fail.

TIA for your thoughts,
Scott

Delivery-date: Mon, 17 Apr 2006 03:00:53 +0000
Date: Sun, 16 Apr 2006 22:59:50 -0400 (EDT)
From: Igor Gashinsky <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---19390912-510927128-1145241272=:13083
Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email-masked]>

On Sun, 16 Apr 2006, marcelo bagnulo braun wrote:

:: Hi Patrick,
:: 
:: El 16/04/2006, a las 20:20, Patrick W. Gilmore escribió:
:: 
:: > It is not just backbones.  Shim6 is not commercially viable.  Period.
:: 
:: Would you care to comment why do you think this?
:: 
:: I mean what are the commercial requirements that shim6 fails to fulfill?
:: Perhaps there is away to make it more similar to what you would expect...
:: 
:: Is this for a certain type of sites, or is it in general for any type of
:: multihomed site?

Marcelo,

	It's the same basic problem that I wrote about earlier. For Shim6 
to be viable, it must be deployed on both the Client and the Server side. 
Given the overhead that this solution would place on the Server side 
to get the job done "right"[1], I do not believe that the Content 
providers would chose to support it (speaking as a network architect for a 
content provider, but again, not officially representing my 
employers views). 

Over the past few months of watching this list, what I've basicly 
witnessed is that people either don't believe that those are 
relevant/realistic requirements, or believe that the current solution's 
benefits outweigh the drawbacks of lack of those features. I really wish 
that people would listen to what Patrick and I are saying, and that as 
engineers for 2 of the worlds largest content networks, we will *not* 
accept a solution that does not meet those requirements, and if you would 
talk to our peers (as we have), neither will they. At this point, without 
content, the solution will be simply useless, since it will not be 
deployed widely enough to matter; sorry, but that's the truth. 

I understand that it's not finished, but I have not seen *1* step towards 
addressing those problems adequately. While I respect the premise that 
engineering is all about making tradeoffs, I just can not accept the 
premise that "the solution" must either be a fully featured system (as we 
have right now in IPv4) or a scalabale routing architecure. That's not a 
"solution", as it does not address the problem it is trying to resolve. 
As Patrick is saying, you can not simply say "we have a solution, it 
breaks lots of stuff you are used to doing, it is going to cause you 
major operational harm, but it's the only thing we can think of right 
now", and expect businesses and bend over backwards to deploy it -- those 
businesses will just say "go back to the drawing boards", and that's 
exactly the message we are trying to pass on.

As far as what Jason/Joe are saying, I really don't believe that the world 
is coming to an end if we continue on our current trend (and Jason, my 
question, again, is "would you really feel the way you do now if you 
didn't miss your last upgrade cycle?"), and neither do our vendors. People 
fully expect for the *current* memory architecture to scale *at least* 
6-fold (and nobody expects for the FIB to expand that much over the next 
5-10 years with the ipv6 adoption, the most aggressive numbers I have 
seen is a 3-4x increase), so I think we have plenty of time to come up 
with a solution which meets all the requirements *and* delivers a more 
scalable routing architecture. At least then, we'll have a real answer, 
and can honestly say that we've "solved the v6 multihoming issues".

Thanks,
-igor (speaking strictly for myself, and not my employer)

[1] Those requirements, which shim6 currently fails to meet, again, are:
1) equal or better TE capabilities to PI multihoming in IPv4
	a) those capabilities controled site wide, not host-wide
	b) those capabilities covering all deployment scenarious that IPv4 
	   currently covers and people use heavily (ie inbound/outbound 
    	   TE, transit TE, partial routes TE, peering TE, etc)
2) equal or better convergence around failures as IPv4 ie (1st packet 
	shim)
3) do all that without an undue burden on the server/SLB/proxy device
---19390912-510927128-1145241272=:13083--

Delivery-date: Sun, 16 Apr 2006 22:05:27 +0000
Content-class: urn:content-classes:message
Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 18:05:17 -0400
From: "Bound, Jim" <[email-masked]>
To: "Patrick W. Gilmore" <[email-masked]>, "Jeroen Massar" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, <[email-masked]>

I don't mind stopping the cross postings.  Can someone send a mail to
where we post this and I will abide?  I suggest this is v6ops discussion
now but I am unclear on how this helps any v6ops deliverable.  It is
kind of like good customer input to SHIM6 and V6OPS?
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Patrick W. Gilmore
> Sent: Sunday, April 16, 2006 1:21 PM
> To: Jeroen Massar
> Cc: Patrick W. Gilmore; shim6-wg; [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 
> advances in ARIN]
> 
> On Apr 16, 2006, at 12:49 PM, Jeroen Massar wrote:
> 
> > [very nice cross posting going on here ;) ]
> 
> Nah, I just hit "reply-all", but only one actually made it through.   
> I'm not subscribed to the rest of the lists.
> 
> I've lowered the CC list to something more reasonable now.
> 
> Oh, and commenting derisively on something you do yourself 
> seems a bit silly.
> 
> 
> > On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:
> > [...
> > large snip about trying to bash shim6 which is not 
> finalized yet, thus 
> > how can you bash it ?
> > Note: extra sarcasm included in this post. Eat the eggs with salt.
> > ...]
> 
> I don't remember bashing shim6.  I remember saying people do 
> not agree it is the way to go.
> 
> As for "finalized", if I don't agree with the basic idea of a 
> technology (e.g. inserting a "shim" into the IP packet), how 
> can you "finalize" it to something with which I will agree?
> 
> 
> >> Oh, and one thing I should have said last time: Technical 
> arguments 
> >> are important, but they are only part of the decision process.
> >
> > In other words: "You are right with your arguments, but I 
> just threw 
> > your args away as they are futile based on the comparison of money 
> > earned this way or the other."...
> 
> I'm going to assume you are being sarcastic here, since your 
> "translation" is factually incorrect.  I was clear the 
> technical arguments are not sufficient, or even close.  I was 
> adding that the business elements are an additional hurdle.
> 
> BTW: Sarcasm is usually intended to either be funny or 
> illustrate a point.  Your sarcasms is definitely not funny, 
> and the only point you are illustrating here is a complete 
> misunderstanding of the discussion at hand.
> 
> 
> >> People (like me) have explained that the Internet is a 
> business, and 
> >> in addition to being .. technically unsavory to many 
> people, shim6 is 
> >> simply not viable in a business setting.
> >
> > And as you will only care for your business for the coming 
> 10 or maybe 
> > 20 years you really can't care what happens to the internet 
> afterward.
> >
> > The idea of IPv6 is (still not was) to have it around for 
> quite some 
> > time longer than the lifespan of IPv4. Fortunately, the PI thing is 
> > far from the end of the world and will only help catch on, 
> see below.
> >
> > Of course any vendor will love the idea of having to do another IP 
> > version of course, bring in the cash ;)
> 
> This is close to a useful argument.
> 
> First, predicting things like router-engine capabilities 20 
> years in the future is beyond silly.
> 
> Second, the is a very real possibility that arguments about 
> 'blowing up the routing table' are completely incorrect.  
> People have been  
> worried about it for over a decade and it has yet to come to pass.   
> (You could argue that it hasn't happened because people are 
> worried about it, but that it true with or without shim6, so 
> it's a wash either way.)
> 
> Lastly, whether it is right or wrong, getting businesses to 
> do something based on a 20 year horizon, especially when it 
> is painful today - and will be for the next 20 years! - is 
> essentially impossible.  So why are you trying to get them to 
> do it?  Personally, I have much more important windmills at 
> which to tilt.
> 
> 
> >> Neither backbone operators
> >> (vendors) nor end users (customers) are warming to the idea.  Just 
> >> the opposite.  (At least in general, the one-in-a-million end user 
> >> with DSL and cable who likes the idea 'cause he can't 
> figure out how 
> >> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)
> >
> > Irrelevant for you as they don't give you money. Indeed, 
> you only look 
> > at your own business interrest (and who can blame you for that ;) 
> > (Once though the internet was there for the masses and not only for 
> > the ones with cash)
> 
> No, irrelevant PERIOD.  You cannot architect the Internet for 
> the one- in-a-million end user, _especially_ one who does not 
> pay for the infrastructure.
> 
> If you argue that they are at all relevant, then we have a 
> lot more problems with shim6 than we've discussed.  (And with 
> the Internet in
> general.)  So please explain to me why they are relevant in 
> any way whatsoever?  I am honestly eager to hear your 
> thinking along this line.
> 
> Just be completely clear on the implications of "proving" a 
> non- paying one-in-a-million end-user is reason enough to 
> change the core architecture of the whole Internet.
> 
> 
> >> So how do you get a technology widely accepted when the 
> majority of 
> >> people involved do not think it is the best technical 
> solution?  When 
> >> the majority of vendors supposed to implement it will not 
> do so for 
> >> technical -and- business reasons.
> >
> > There is for you indeed a business reason to not like it: 
> the end-site 
> > won't have any reason to stick to the upstream. Which is 
> indeed a bad 
> > business for many of the 'vendors' you mean.
> >
> > As Eliot Lear also said very clearly: Thanks for lining the vendors 
> > and all the stockholders pockets ;)
> 
> I'm not a backbone.  I am personally an end user.  And my 
> company is not a backbone, and does not sell transit to 
> anyone.  In fact, we are  
> probably the largest "end-site" consumer of bandwidth in the world.   
> And I still dislike shim6 both technically and commercially, 
> personally and professionally.  So does every technical 
> person at my company who has any interest in this topic.
> 
> It is not just backbones.  Shim6 is not commercially viable.  Period.
> 
> But thank you for attempting to divert the real discussion.
> 
> 
> > That is in the long run, most likely in the coming 10-20 years the
> > IPv6
> > routing tables will not have 'exploded' yet, but the folks selling 
> > equipment and having stocks of those venders after that most likely 
> > will have a nice retirement fund. Thanks to you!
> 
> First, thank you for thinking I am so important.
> 
> Second: Whatever.  If you honestly believe cisco & juniper 
> will fail or succeed based on shim6, you really need to 
> reevaluate your hypothesis.
> 
> 
> > Nevertheless, the PI thing is really *not* a bad thing, as 
> it can be 
> > used as an identifier for shim6, which is actually perfect. It just 
> > saves on having to do a complete policy process for getting address 
> > space for this type of usage. But thanks to this, this 
> won't be needed 
> > and thus in the end anybody who can get PI can use a shim6-alike 
> > solution and won't have any problem with the upstream that actually 
> > wanted to lock them in by letting them pay loads for an 
> entry in the 
> > BGP tables.
> >
> > Thus people voting for PI, thanks for helping shim6 or another 
> > solution in that space, progress a lot :)
> 
> Then why are we arguing about this?
> 
> --
> TTFN,
> patrick
> 
> 

Delivery-date: Sun, 16 Apr 2006 22:03:32 +0000
Content-class: urn:content-classes:message
Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 18:03:22 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Patrick W. Gilmore" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, <[email-masked]>, <[email-masked]>, "IETF Discussion" <[email-masked]>, <[email-masked]>, <[email-masked]>

The IETF has NOTHING to say anymore than any other body about any RIR
policy. I want it to remain that way.  IETF job is a standards body not
a deployment body.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Sunday, April 16, 2006 3:18 AM
> To: Patrick W. Gilmore
> Cc: shim6-wg; [email-masked]; [email-masked]; IETF 
> Discussion; [email-masked]; [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 
> advances in ARIN]
> 
> On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote:
> 
> > Wow, Iljitsch, I have never lost so much respect so quickly for  
> > someone who was not flaming a specific person or using profanity.   
> > Congratulations.
> 
> Well, that's too bad. But several years of trying to get a 
> scalable multihoming off the ground (flying to different 
> meetings on my own
> dime) where first my ideas about PI aggregation are rejected 
> within the IETF mostly without due consideration because it 
> involves the taboo word "geography" only to see the next best 
> thing being rejected by people who, as far as I can tell, 
> lack a view of the big picture, is enough to make me lose my 
> cool. Just a little.
> 
> > Back on topic, it is not just those 60 people - the "playground"  
> > appears to overwhelmingly agree with their position.  I know I do.
> 
> Don't you think it's strange that the views within ARIN are 
> so radically different than those within the IETF? Sure, 
> inside the IETF there are also people who think PI in IPv6 
> won't be a problem, but it's not the majority (as far as I 
> can tell) and certainly not anything close to 90%. Now the 
> IETF process isn't perfect, as many things depend on whether 
> people feel like actually doing something.  
> But many of the best and the brightest in the IETF have been 
> around for some time in multi6 and really looked at the 
> problem. Many, if not most, of them concluded that we need 
> something better than IPv4 practices to make IPv6 last as 
> long as we need it to last. Do you think all of them were wrong?
> 
> > I am sorry your technical arguments have not persuaded us 
> in the past.  
> > But I would urge you to stick to those,
> 
> Stay tuned.
> 
> 

Delivery-date: Sun, 16 Apr 2006 22:02:14 +0000
Content-class: urn:content-classes:message
Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 18:02:04 -0400
From: "Bound, Jim" <[email-masked]>
To: "Patrick W. Gilmore" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, <[email-masked]>, <[email-masked]>, "IETF Discussion" <[email-masked]>, <[email-masked]>, <[email-masked]>

I agree.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Patrick W. Gilmore
> Sent: Sunday, April 16, 2006 12:10 AM
> To: Iljitsch van Beijnum
> Cc: Patrick W. Gilmore; shim6-wg; [email-masked]; 
> [email-masked]; IETF Discussion; 
> [email-masked]; [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 
> advances in ARIN]
> 
> On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote:
> 
> > On 14-apr-2006, at 16:57, Scott Leibrand wrote:
> >
> >> 60 voted in favor of moving forward with PI.  6 voted against.
> >
> > Wow, 10 to 1. Amazing.
> >
> > Even more amazing: 60 people who represent nobody but their own 
> > paycheck get to blow up the internet.
> >
> > Where is ICANN when you need it? This little experiment in 
> playground 
> > democracy has to end before people get hurt.
> 
> Wow, Iljitsch, I have never lost so much respect so quickly for  
> someone who was not flaming a specific person or using profanity.   
> Congratulations.
> 
> 
> Back on topic, it is not just those 60 people - the "playground"  
> appears to overwhelmingly agree with their position.  I know I do.
> 
> I am sorry your technical arguments have not persuaded us in 
> the past.  But I would urge you to stick to those, or at 
> least consider why we remain unconvinced, rather than devolve 
> into .. whatever that post was supposed to be.
> 
> --
> TTFN,
> patrick
> 
> 

Delivery-date: Sun, 16 Apr 2006 21:59:45 +0000
Content-class: urn:content-classes:message
Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 17:59:32 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Scott Leibrand" <[email-masked]>
Cc: "Jason [email-masked]" <[email-masked]>, "Joe Abley" <[email-masked]>, "shim6-wg" <[email-masked]>, <[email-masked]>

Well that is how RIRs are structured and supported by ICANN.  
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, April 14, 2006 11:07 AM
> To: Scott Leibrand
> Cc: Jason [email-masked]; Joe Abley; shim6-wg; 
> [email-masked]; [email-masked]; IETF Discussion; 
> [email-masked]; [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 
> advances in ARIN]
> 
> On 14-apr-2006, at 16:57, Scott Leibrand wrote:
> 
> > 60 voted in favor of moving forward with PI.  6 voted against.
> 
> Wow, 10 to 1. Amazing.
> 
> Even more amazing: 60 people who represent nobody but their 
> own paycheck get to blow up the internet.
> 
> Where is ICANN when you need it? This little experiment in 
> playground democracy has to end before people get hurt.
> 
> 
> 

Delivery-date: Sun, 16 Apr 2006 21:58:20 +0000
Content-class: urn:content-classes:message
Subject: RE: PI addressing in IPv6 advances in ARIN
Date: Sun, 16 Apr 2006 17:58:09 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Durand, Alain" <[email-masked]>
Cc: "Craig Huegen (chuegen)" <[email-masked]>, <[email-masked]>, <[email-masked]>

ALso if those prefixes are for a nuclear power plant I want them to have
proper time to renumber for sure.  It is relevant to what business
impact it has specifically in mission critical environments.  I am
removing all but IETF lists in my responses.
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, April 14, 2006 10:41 AM
> To: Durand, Alain
> Cc: Craig Huegen (chuegen); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: PI addressing in IPv6 advances in ARIN
> 
> On 14-apr-2006, at 16:02, Durand, Alain wrote:
> 
> >> Maybe I'm being overly simplistic, but the policy can set 
> a recovery 
> >> timeframe in its allocation of PI space to end users and 
> the market 
> >> forces can drive the recovery based on the impact to the 
> >> infrastructure.
> >> If only a few hundred prefixes are handed out, it might 
> not be enough 
> >> of a problem to force recovery.
> 
> > One could argue that if we are only talking about a few hundred 
> > prefixes, Why do we care reclaiming them?
> 
> If the number of prefixes becomes large enough to be 
> problematic, reclaiming those to solve these problems isn't 
> going to work. For one thing, it's likely that such problems 
> won't be experienced to the same degree by different people: 
> people with a few large routers (and deep pockets) will be in 
> a much better position than people with a larger number of 
> smaller routers (and less money). Also, policy development is 
> done regionally while the results are suffered globally. But 
> even discounting all of that, if ARIN were to decide that the 
> prefixes must be revoked, it will take a significant amount 
> of time before that actually happens. It gets worse when 
> people start to sue.
> 
> So in practice the only thing that can happen is that if the 
> problem is severe (i.e., that 51% of all people in the (rich) 
> ARIN region feel the pain) the policy is changed so that no 
> _new_ prefixes of this type are given out, and then we have 
> to wait for the increase in router performance over time to 
> make the problem disappear.
> 
> If it gets really bad a quick "ipv6 prefix-list no-v6-pi deny 
> ::/0 ge 48" will clean up the routing table and a timeout or 
> two later you're back on IPv4 when trying to reach the 
> holders of these PI blocks.
> 
> 

Delivery-date: Sun, 16 Apr 2006 21:56:37 +0000
Content-class: urn:content-classes:message
Subject: RE: PI addressing in IPv6 advances in ARIN
Date: Sun, 16 Apr 2006 17:55:50 -0400
To: "Craig Huegen (chuegen)" <[email-masked]>, "Durand, Alain" <[email-masked]>, <[email-masked]>, <[email-masked]>

Regarding Address Reclaim.  My private individual input to RIR is that
the private sector should have binding legal agreement with any LIR that
they cannot force a renumber without proper X time to renumber which
would be different depending on the business impact real time of a
renumbering operation.  Not clear how Governments will operate as they
are truly ISPs and the issue could be moot to them.

/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Craig Huegen (chuegen)
> Sent: Friday, April 14, 2006 9:21 AM
> To: Durand, Alain; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: PI addressing in IPv6 advances in ARIN
> 
> On Friday, April 14, 2006 6:54 AM, Alain Durand wrote:
> 
> > A) if PI addresses are to be returned at some point in time, they 
> > loose a dreat deal of their value. Folks like PI because it shields 
> > them from renumbering.
> 
> I'd like to clarify this a bit.  As a large enterprise 
> network operator, I'm less concerned about the need to 
> renumber the network once than I am the need to renumber 
> every time that I want to change a service provider.  Don't 
> take that the wrong way:  renumbering is still a significant 
> pain, but the real reason that enterprises haven't adopted PA 
> space is that it represents a de-facto "lock-in" to the 
> service providers they choose initially and they're faced 
> with a network-wide renumber any time they drop or add a 
> service provider.
> 
> Most enterprise network operators that I have spoken to would 
> be willing to renumber once in the future, in exchange for a 
> reasonable way to get portable IPv6 space today.
> 
> > B) any address reclaim process might be lenghty and costly
> 
> Maybe I'm being overly simplistic, but the policy can set a 
> recovery timeframe in its allocation of PI space to end users 
> and the market forces can drive the recovery based on the 
> impact to the infrastructure.
> If only a few hundred prefixes are handed out, it might not 
> be enough of a problem to force recovery.
> 
> This may be a moot point for the ARIN discussion, though, as 
> ARIN typically doesn't play all that much of an enforcer 
> role.  It can declare prefixes and prefix ranges as dead, but 
> reachability is determined by the service providers.
> 
> > C) given how long the shim6/multi homing has taken so far, it seems 
> > hazardous to make any bet that in 3 years it will be finish, 
> > implemented, adopted, deployed...
> 
> I think that Jordi was referring to 3 years after the 
> solution is declared "available" -- admittedly that's a tough 
> milestone to set.
> 
> Finally, I agree with all four other points you make; 
> adoption of IPv6 has been held up because the capabilities 
> offered lack a critical requirement for enterprise networks 
> (connectivity without de-facto service provider lock-in).  
> The agreement to move forward with a policy is a very 
> positive thing that enables IPv6 to work for large 
> enterprises while the right solution is determined and rolled out.
> 
> /cah
> 
> ---
> Craig A. Huegen, IT Solutions Architect       C i s c o  S y s t e m s
> IT - Intelligent Network Solutions                  ||        ||
> Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
> San Jose, CA  95134, (408) 526-8104                ||||      ||||
> email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..
> 
> 

Delivery-date: Sun, 16 Apr 2006 21:51:10 +0000
Content-class: urn:content-classes:message
Subject: RE: PI addressing in IPv6 advances in ARIN
Date: Sun, 16 Apr 2006 17:51:03 -0400
From: "Bound, Jim" <[email-masked]>
To: "Durand, Alain" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

I am not sure this is valid discussion for v6ops with respect to a
deliverable from v6ops because IETF has no more input to the RIRs than
GM, BT, Governments etc.  

V6ops Chairs: Is this valid discussion to any of our working group
deliverables other than good fyi to the team?  Thanks

/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Durand, Alain
> Sent: Friday, April 14, 2006 7:54 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: PI addressing in IPv6 advances in ARIN
> 
> Wrt Jordi's proposal:
> 
> I have sympathy to the idea of balancing PI need with routing 
> table growth, however:
> 
> A) if PI addresses are to be returned at some point in time, 
> they loose a dreat deal of their value. Folks like PI because 
> it shields them from renumbering.
> 
> B) any address reclaim process might be lenghty and costly
> 
> C) given how long the shim6/multi homing has taken so far, it 
> seems hazardous to make any bet that in 3 years it will be 
> finish, implemented, adopted, deployed...
> 
> D) I am sensitive to the argument that v4 has not "melted" 
> with PI, so why should v6 melt more? I believe the benefits 
> of handing out PI *now* outweight the cost of a *small* swamp. 
> 
> E) given the state of v6 deployment now, I do not think there 
> is much risk with this policy at this moment. And as Thomas 
> relayed, this policy could be changed anyway if things get 
> out of control.
> 
> F) if this means giving advantage to the early adopters by 
> offering them PI, I look at this as a positive thing.
> 
> G) a key thing is to limit the size of the swamp that would 
> be created, or more specifically limit its growth. So it 
> might be a good idea to have a sunset clause in the policy, 
> like it will have to be revisited in 2 years or when a 
> certain allocation (or allocation rate) threshold will be reached.
> 
>     - Alain.
> 

Delivery-date: Sun, 16 Apr 2006 21:47:40 +0000
Content-class: urn:content-classes:message
Subject: RE: PI addressing in IPv6 advances in ARIN
Date: Sun, 16 Apr 2006 17:46:48 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Jordi, thanks.  I completely disagree with you.  So we can debate as apppropriate, but at the end of the day any RIR only accepts input from "individuals" not organizations. 

Thanks for your response.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 14, 2006 6:20 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: PI addressing in IPv6 advances in ARIN
> 
> Hi Jim,
> 
> Not sure if I got your question correctly, but let me try to 
> explain my view.
> 
> I understand the position of the people that say they need PI 
> today, especially because not having it may be hurting the 
> advancement of the IPv6 deployment.
> 
> However, I want to balance this with the medium-long term 
> implications created in the routing table and with the time 
> needed to build and deploy a better technical solution (or 
> several) which is accepted by the community.
> 
> So my proposal basically is about having PI now everywhere 
> (once ARIN adopt it, is unfair not having it in other 
> regions), but those PI allocations for multihoming should be 
> temporary and those address blocks returned to the RIRs some 
> time (lets say 3 years) after the new technical solution is 
> declared as a valid one.
> 
> At this way, on the long-run, we will not have routing table 
> implications, but we allow now the people that want to move 
> ahead only if they have a multihoming solution doing so.
> 
> This 3-years time for getting a multihoming network back to 
> the new technical solution (once adopted) is enough time, I 
> think (it could be changed to 5 years if needed, or 
> whatever), so nobody today see the temporarily of the 
> proposal as a showstopper to go for it now.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: "Bound, Jim" <[email-masked]>
> > Responder a: <[email-masked]>
> > Fecha: Fri, 14 Apr 2006 03:11:58 -0400
> > Para: <[email-masked]>, <[email-masked]>
> > Conversación: PI addressing in IPv6 advances in ARIN
> > Asunto: RE: PI addressing in IPv6 advances in ARIN
> > 
> > Jordi, why this will work as is for now?
> > /jim
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
> >> Sent: Thursday, April 13, 2006 5:28 PM
> >> To: [email-masked]
> >> Subject: Re: PI addressing in IPv6 advances in ARIN
> >> 
> >> Hi Thomas, all,
> >> 
> >> During my fly-back from Montreal, I've worked in a 
> proposal and I'm 
> >> talking to folks in each RIR/region, with the idea to submit it to 
> >> all them as a kind of (if possible), global policy.
> >> 
> >> The idea is based on the comments that I did at the mic during the 
> >> ARIN meeting.
> >> 
> >> I will try to get this submitted next Monday/Tuesday and get ready 
> >> for a formal presentation during the next RIPE meeting at Istanbul 
> >> (following week).
> >> 
> >> Regards,
> >> Jordi
> >> 
> >> 
> >> 
> >> 
> >>> De: Thomas Narten <[email-masked]> Responder a: 
> >>> <[email-masked]>
> >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400
> >>> Para: "Gunter Van de Velde (gvandeve)" <[email-masked]>
> >>> CC: "[email-masked]" <[email-masked]>
> >>> Asunto: Re: PI addressing in IPv6 advances in ARIN
> >>> 
> >>>> What would be the prefix allocation per organization?
> >>> 
> >>> /48, though can be larger in some cases. Watch for the revised 
> >>> proposal that gets last called for details.
> >>> 
> >>>> (Me being in Europe and not attending ARIN sessions)
> >>> 
> >>> Note: none of the other RIRs have such a policy in place
> >> today, though
> >>> I wouldn't be surprised if they now followup with proposals
> >> of their
> >>> own (though someone has to do it).
> >>> 
> >>>> Has there been study on the # of organizations going for
> >> this and if
> >>>> the impact will be more significant then more's law on 
> technology 
> >>>> enhancement?
> >>> 
> >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today,"
> >>> "looking at the impact of the current IPv4 policies, the
> >> number of PI
> >>> assignments is only on the 100s per year", and "we can update the 
> >>> policy if things get problematical".
> >>> 
> >>> Thomas
> >>> 
> >> 
> >> 
> >> 
> >> 
> >> **********************************************
> >> The IPv6 Portal: http://www.ipv6tf.org
> >> 
> >> Barcelona 2005 Global IPv6 Summit
> >> Slides available at:
> >> http://www.ipv6-es.com
> >> 
> >> This electronic message contains information which may be 
> privileged 
> >> or confidential. The information is intended to be for the 
> use of the 
> >> individual(s) named above. If you are not the intended 
> recipient be 
> >> aware that any disclosure, copying, distribution or use of the 
> >> contents of this information, including attached files, is 
> >> prohibited.
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> 
> 

Delivery-date: Sun, 16 Apr 2006 19:37:49 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 22:37:09 +0300
To: "Patrick W. Gilmore" <[email-masked]>

Hi Patrick,

El 16/04/2006, a las 20:20, Patrick W. Gilmore escribió:

> It is not just backbones.  Shim6 is not commercially viable.  Period.
>

Would you care to comment why do you think this?

I mean what are the commercial requirements that shim6 fails to 
fulfill? Perhaps there is away to make it more similar to what you 
would expect...

Is this for a certain type of sites, or is it in general for any type 
of multihomed site?

Thanks, marcelo

Delivery-date: Sun, 16 Apr 2006 19:10:10 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 15:09:40 -0400
To: Jeroen Massar <[email-masked]>

On Apr 16, 2006, at 2:09 PM, Jeroen Massar wrote:

>>> On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:

>> I don't remember bashing shim6.  I remember saying people do not
>> agree it is the way to go.
>>
>> As for "finalized", if I don't agree with the basic idea of a
>> technology (e.g. inserting a "shim" into the IP packet), how can you
>> "finalize" it to something with which I will agree?
>
> How can you not agree with something which is not there yet?
> You don't like super-duper space engines yet either?

Not if the people doing so have as a basic requirement something that  
I find intollerable.

You say it is not "finalized".  I say these are implementation  
details.  Does shim6 require a "shim" to be inserted?  Or is that  
something that might be "finalized" away?  If the final version is so  
different on such a basic level, then I submit that you are no longer  
discussing shim6.

> As mentioned, from a business point of view I agree totally, I  
> would not
> want it either. From a tech point of view, it will be one of the  
> better
> things since sliced bread. The future will tell though.

 From a business PoV, it is silly.  Since businesses have to  
implement it, that's a show-stopper right there.

 From a technical PoV, the overwhelming consensus is that it is not  
very good, and not even close to the optimal solution.  Since  
technical people, that's a show-stopper right there.

Two show-stoppers at such basic levels are hard to overcome by  
"finalizing" a protocol.

>> BTW: Sarcasm is usually intended to either be funny or illustrate a
>> point.  Your sarcasms is definitely not funny, and the only point you
>> are illustrating here is a complete misunderstanding of the
>> discussion at hand.
>
> The discussion: "yeah shim6 is dead, long live PI".
> Very hard indeed.

I never said shim6 is dead.  I said the majority of people who work  
on the Internet - you know, the people who actually have to live with  
this if it comes to pass - all wish it were dead.

And hell yes, "long live PI".

>>> And as you will only care for your business for the coming 10 or  
>>> maybe
>>> 20 years you really can't care what happens to the internet  
>>> afterward.
> [..]
>> This is close to a useful argument.
>>
>> First...
> [..]
>
> I would not agree less.

Not really sure what you meant there.

>>>> Neither backbone operators
>>>> (vendors) nor end users (customers) are warming to the idea.  Just
>>>> the opposite.  (At least in general, the one-in-a-million end user
>>>> with DSL and cable who likes the idea 'cause he can't figure out  
>>>> how
>>>> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)
>>>
>>> Irrelevant for you as they don't give you money. Indeed, you only  
>>> look
>>> at your own business interrest (and who can blame you for that ;)
>>> (Once though the internet was there for the masses and not only for
>>> the
>>> ones with cash)
>>
>> No, irrelevant PERIOD.  You cannot architect the Internet for the  
>> one-
>> in-a-million end user, _especially_ one who does not pay for the
>> infrastructure.
>
> Isn't that like *exactly* what I wrote there: "They don't _pay you_
> money and thus you don't care about them."

What you said is that they don't pay me therefore they don't matter.   
What I said is please show me (all of us) why the one-in-a-million  
user should dictate how the Internet works.  I added that they are  
not paying for the _infrastructure_, not me personally.  If they pay  
someone else to upgrade the infrastructure, that's good enough for me.

> Which is perfectly valid from a business point of view. But it is
> totally not perfect when looking at what the IETF wanted to achieve  
> with
> PA-only space.

What the IETF wanted to achieve with PA-only space had nothing to do  
with that one-in-a-million user.

Just the opposite.  They were trying to handcuff the other 999,999  
users.

> Some people tend to the little guys, other only cash in on the big  
> ones.
> That is business. But that has nothing to do with engineering a sound
> protocol.

Neither does changing the whole architecture of the Internet for a  
corner case.  In fact, doing so is far less sound.  IMHO.

>> It is not just backbones.  Shim6 is not commercially viable.  Period.
>
> As I also mentioned, there is enough interrest for it, if you don't  
> want
> it then simply ignore it.

I'm a little confused by the statement "there is enough interrest  
[sic] for it".  Enough interest for what?  Continuing development?   
Protocol implementation?  Trading flames on mailing lists?

>>> That is in the long run, most likely in the coming 10-20 years the
>>> IPv6
>>> routing tables will not have 'exploded' yet, but the folks selling
>>> equipment and having stocks of those venders after that most likely
>>> will
>>> have a nice retirement fund. Thanks to you!

[...]

>> Second: Whatever.  If you honestly believe cisco & juniper will fail
>> or succeed based on shim6, you really need to reevaluate your
>> hypothesis.
>
> Those companies can't care less, why should they, they can keep on
> selling bigger fatter newer shinier boxes anyway.

Then what was your point above?

-- 
TTFN,
patrick

Delivery-date: Sun, 16 Apr 2006 18:10:11 +0000
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
From: Jeroen Massar <[email-masked]>
To: "Patrick W. Gilmore" <[email-masked]>
Cc: shim6-wg <[email-masked]>, [email-masked]
Organization: Unfix
Date: Sun, 16 Apr 2006 20:09:45 +0200

--=-eBsQrCwfCW+qQ22Ppg9V
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2006-04-16 at 13:20 -0400, Patrick W. Gilmore wrote:
> On Apr 16, 2006, at 12:49 PM, Jeroen Massar wrote:
> 
> > [very nice cross posting going on here ;) ]
> 
> Nah, I just hit "reply-all", but only one actually made it through.   
> I'm not subscribed to the rest of the lists.
> 
> I've lowered the CC list to something more reasonable now.
> 
> Oh, and commenting derisively on something you do yourself seems a  
> bit silly.

Well, just like you, I also nicely hit 'reply-all', except that I am on
the other lists too, thus now your original message did mostly come
through anyway.

> > On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:
> > [...
> > large snip about trying to bash shim6 which is not finalized
> > yet, thus how can you bash it ?
> > Note: extra sarcasm included in this post. Eat the eggs with salt.
> > ...]
> 
> I don't remember bashing shim6.  I remember saying people do not  
> agree it is the way to go.
>
> As for "finalized", if I don't agree with the basic idea of a  
> technology (e.g. inserting a "shim" into the IP packet), how can you  
> "finalize" it to something with which I will agree?

How can you not agree with something which is not there yet?
You don't like super-duper space engines yet either?

As mentioned, from a business point of view I agree totally, I would not
want it either. From a tech point of view, it will be one of the better
things since sliced bread. The future will tell though.

> >> Oh, and one thing I should have said last time: Technical arguments
> >> are important, but they are only part of the decision process.
> >
> > In other words: "You are right with your arguments, but I just threw
> > your args away as they are futile based on the comparison of money
> > earned this way or the other."...
> 
> I'm going to assume you are being sarcastic here, since your  
> "translation" is factually incorrect.  I was clear the technical  
> arguments are not sufficient, or even close.  I was adding that the  
> business elements are an additional hurdle.

Yes, there is some work to be done on shim6, but as long as it isn't
complete, don't say that it is dead already.

> BTW: Sarcasm is usually intended to either be funny or illustrate a  
> point.  Your sarcasms is definitely not funny, and the only point you  
> are illustrating here is a complete misunderstanding of the  
> discussion at hand.

The discussion: "yeah shim6 is dead, long live PI".
Very hard indeed.

> >> People (like me) have explained that the Internet is a business, and
> >> in addition to being .. technically unsavory to many people, shim6 is
> >> simply not viable in a business setting.
> >
> > And as you will only care for your business for the coming 10 or maybe
> > 20 years you really can't care what happens to the internet afterward.
[..]
> This is close to a useful argument.
> 
> First...
[..]

I would not agree less.

> >> Neither backbone operators
> >> (vendors) nor end users (customers) are warming to the idea.  Just
> >> the opposite.  (At least in general, the one-in-a-million end user
> >> with DSL and cable who likes the idea 'cause he can't figure out how
> >> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)
> >
> > Irrelevant for you as they don't give you money. Indeed, you only look
> > at your own business interrest (and who can blame you for that ;)
> > (Once though the internet was there for the masses and not only for  
> > the
> > ones with cash)
> 
> No, irrelevant PERIOD.  You cannot architect the Internet for the one- 
> in-a-million end user, _especially_ one who does not pay for the  
> infrastructure.

Isn't that like *exactly* what I wrote there: "They don't _pay you_
money and thus you don't care about them."
Which is perfectly valid from a business point of view. But it is
totally not perfect when looking at what the IETF wanted to achieve with
PA-only space.

Some people tend to the little guys, other only cash in on the big ones.
That is business. But that has nothing to do with engineering a sound
protocol.

[..]
> And I still dislike shim6 both technically and commercially,  
> personally and professionally.  So does every technical person at my  
> company who has any interest in this topic.

As I wrote in the previous mail, just wait till shim6 is finalized then
start flaming it. Nevertheless, it should be backward compatible and it
will 

> It is not just backbones.  Shim6 is not commercially viable.  Period.

As I also mentioned, there is enough interrest for it, if you don't want
it then simply ignore it.

> > That is in the long run, most likely in the coming 10-20 years the  
> > IPv6
> > routing tables will not have 'exploded' yet, but the folks selling
> > equipment and having stocks of those venders after that most likely  
> > will
> > have a nice retirement fund. Thanks to you!
> 
> First, thank you for thinking I am so important.

Well the "you" is the group of people who arranged the PI. But if you
want to take the credit, they are all yours ;)

> Second: Whatever.  If you honestly believe cisco & juniper will fail  
> or succeed based on shim6, you really need to reevaluate your  
> hypothesis.

Those companies can't care less, why should they, they can keep on
selling bigger fatter newer shinier boxes anyway.

> > Nevertheless, the PI thing is really *not* a bad thing, as it can be
> > used as an identifier for shim6, which is actually perfect. It just
> > saves on having to do a complete policy process for getting address
> > space for this type of usage. But thanks to this, this won't be needed
> > and thus in the end anybody who can get PI can use a shim6-alike
> > solution and won't have any problem with the upstream that actually
> > wanted to lock them in by letting them pay loads for an entry in  
> > the BGP
> > tables.
> >
> > Thus people voting for PI, thanks for helping shim6 or another  
> > solution
> > in that space, progress a lot :)
> 
> Then why are we arguing about this?

Did I argue? I only commented about some of your statements to which I
don't agree.

Greets,
 Jeroen

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

--=-eBsQrCwfCW+qQ22Ppg9V--

Delivery-date: Sun, 16 Apr 2006 17:21:13 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 13:20:36 -0400
To: Jeroen Massar <[email-masked]>

On Apr 16, 2006, at 12:49 PM, Jeroen Massar wrote:

> [very nice cross posting going on here ;) ]

Nah, I just hit "reply-all", but only one actually made it through.   
I'm not subscribed to the rest of the lists.

I've lowered the CC list to something more reasonable now.

Oh, and commenting derisively on something you do yourself seems a  
bit silly.

> On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:
> [...
> large snip about trying to bash shim6 which is not finalized
> yet, thus how can you bash it ?
> Note: extra sarcasm included in this post. Eat the eggs with salt.
> ...]

I don't remember bashing shim6.  I remember saying people do not  
agree it is the way to go.

As for "finalized", if I don't agree with the basic idea of a  
technology (e.g. inserting a "shim" into the IP packet), how can you  
"finalize" it to something with which I will agree?

>> Oh, and one thing I should have said last time: Technical arguments
>> are important, but they are only part of the decision process.
>
> In other words: "You are right with your arguments, but I just threw
> your args away as they are futile based on the comparison of money
> earned this way or the other."...

I'm going to assume you are being sarcastic here, since your  
"translation" is factually incorrect.  I was clear the technical  
arguments are not sufficient, or even close.  I was adding that the  
business elements are an additional hurdle.

BTW: Sarcasm is usually intended to either be funny or illustrate a  
point.  Your sarcasms is definitely not funny, and the only point you  
are illustrating here is a complete misunderstanding of the  
discussion at hand.

>> People (like me) have explained that the Internet is a business, and
>> in addition to being .. technically unsavory to many people, shim6 is
>> simply not viable in a business setting.
>
> And as you will only care for your business for the coming 10 or maybe
> 20 years you really can't care what happens to the internet afterward.
>
> The idea of IPv6 is (still not was) to have it around for quite some
> time longer than the lifespan of IPv4. Fortunately, the PI thing is  
> far
> from the end of the world and will only help catch on, see below.
>
> Of course any vendor will love the idea of having to do another IP
> version of course, bring in the cash ;)

This is close to a useful argument.

First, predicting things like router-engine capabilities 20 years in  
the future is beyond silly.

Second, the is a very real possibility that arguments about 'blowing  
up the routing table' are completely incorrect.  People have been  
worried about it for over a decade and it has yet to come to pass.   
(You could argue that it hasn't happened because people are worried  
about it, but that it true with or without shim6, so it's a wash  
either way.)

Lastly, whether it is right or wrong, getting businesses to do  
something based on a 20 year horizon, especially when it is painful  
today - and will be for the next 20 years! - is essentially  
impossible.  So why are you trying to get them to do it?  Personally,  
I have much more important windmills at which to tilt.

>> Neither backbone operators
>> (vendors) nor end users (customers) are warming to the idea.  Just
>> the opposite.  (At least in general, the one-in-a-million end user
>> with DSL and cable who likes the idea 'cause he can't figure out how
>> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)
>
> Irrelevant for you as they don't give you money. Indeed, you only look
> at your own business interrest (and who can blame you for that ;)
> (Once though the internet was there for the masses and not only for  
> the
> ones with cash)

No, irrelevant PERIOD.  You cannot architect the Internet for the one- 
in-a-million end user, _especially_ one who does not pay for the  
infrastructure.

If you argue that they are at all relevant, then we have a lot more  
problems with shim6 than we've discussed.  (And with the Internet in  
general.)  So please explain to me why they are relevant in any way  
whatsoever?  I am honestly eager to hear your thinking along this line.

Just be completely clear on the implications of "proving" a non- 
paying one-in-a-million end-user is reason enough to change the core  
architecture of the whole Internet.

>> So how do you get a technology widely accepted when the majority of
>> people involved do not think it is the best technical solution?  When
>> the majority of vendors supposed to implement it will not do so for
>> technical -and- business reasons.
>
> There is for you indeed a business reason to not like it: the end-site
> won't have any reason to stick to the upstream. Which is indeed a bad
> business for many of the 'vendors' you mean.
>
> As Eliot Lear also said very clearly: Thanks for lining the vendors  
> and
> all the stockholders pockets ;)

I'm not a backbone.  I am personally an end user.  And my company is  
not a backbone, and does not sell transit to anyone.  In fact, we are  
probably the largest "end-site" consumer of bandwidth in the world.   
And I still dislike shim6 both technically and commercially,  
personally and professionally.  So does every technical person at my  
company who has any interest in this topic.

It is not just backbones.  Shim6 is not commercially viable.  Period.

But thank you for attempting to divert the real discussion.

> That is in the long run, most likely in the coming 10-20 years the  
> IPv6
> routing tables will not have 'exploded' yet, but the folks selling
> equipment and having stocks of those venders after that most likely  
> will
> have a nice retirement fund. Thanks to you!

First, thank you for thinking I am so important.

Second: Whatever.  If you honestly believe cisco & juniper will fail  
or succeed based on shim6, you really need to reevaluate your  
hypothesis.

> Nevertheless, the PI thing is really *not* a bad thing, as it can be
> used as an identifier for shim6, which is actually perfect. It just
> saves on having to do a complete policy process for getting address
> space for this type of usage. But thanks to this, this won't be needed
> and thus in the end anybody who can get PI can use a shim6-alike
> solution and won't have any problem with the upstream that actually
> wanted to lock them in by letting them pay loads for an entry in  
> the BGP
> tables.
>
> Thus people voting for PI, thanks for helping shim6 or another  
> solution
> in that space, progress a lot :)

Then why are we arguing about this?

-- 
TTFN,
patrick

Delivery-date: Sun, 16 Apr 2006 16:11:22 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked], IETF Discussion <[email-masked]>, [email-masked], [email-masked]
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 12:10:36 -0400
To: Iljitsch van Beijnum <[email-masked]>

On Apr 16, 2006, at 3:17 AM, Iljitsch van Beijnum wrote:

> On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote:
>
>> Wow, Iljitsch, I have never lost so much respect so quickly for  
>> someone who was not flaming a specific person or using profanity.   
>> Congratulations.
>
> Well, that's too bad. But several years of trying to get a scalable  
> multihoming off the ground (flying to different meetings on my own  
> dime) where first my ideas about PI aggregation are rejected within  
> the IETF mostly without due consideration because it involves the  
> taboo word "geography" only to see the next best thing being  
> rejected by people who, as far as I can tell, lack a view of the  
> big picture, is enough to make me lose my cool. Just a little.

Thank you for believing my opposition of your ideas is simply because  
I "lack a view of the big picture".  Note that it is entirely  
possible I believe the reverse to be true.  Or perhaps you see a big  
picture, and I just see a bigger one.

However, I probably won't lose my cool since, as I stated before, the  
overwhelming majority of people who run the Internet seem to see my  
"bigger" picture.

>> Back on topic, it is not just those 60 people - the "playground"  
>> appears to overwhelmingly agree with their position.  I know I do.
>
> Don't you think it's strange that the views within ARIN are so  
> radically different than those within the IETF? Sure, inside the  
> IETF there are also people who think PI in IPv6 won't be a problem,  
> but it's not the majority (as far as I can tell) and certainly not  
> anything close to 90%. Now the IETF process isn't perfect, as many  
> things depend on whether people feel like actually doing something.  
> But many of the best and the brightest in the IETF have been around  
> for some time in multi6 and really looked at the problem. Many, if  
> not most, of them concluded that we need something better than IPv4  
> practices to make IPv6 last as long as we need it to last. Do you  
> think all of them were wrong?

Yes.

And so does essentially everyone else who runs an Internet backbone.   
These are some of the "best and brightest" in the world, and most of  
them have been around for .. well, 'forever' in Internet terms.

But decision such as these really shouldn't be decided simply because  
someone has been doing this longer.

>> I am sorry your technical arguments have not persuaded us in the  
>> past.  But I would urge you to stick to those,
>
> Stay tuned.

I'll try.  But honestly, reading the same arguments over and over  
gets tiresome, especially when so many well-qualified people have  
explained the opposing PoV so well.

Oh, and one thing I should have said last time: Technical arguments  
are important, but they are only part of the decision process.   
People (like me) have explained that the Internet is a business, and  
in addition to being .. technically unsavory to many people, shim6 is  
simply not viable in a business setting.  Neither backbone operators  
(vendors) nor end users (customers) are warming to the idea.  Just  
the opposite.  (At least in general, the one-in-a-million end user  
with DSL and cable who likes the idea 'cause he can't figure out how  
to spell "B-G-P" or doesn't want to pay for it is irrelevant.)

So how do you get a technology widely accepted when the majority of  
people involved do not think it is the best technical solution?  When  
the majority of vendors supposed to implement it will not do so for  
technical -and- business reasons.  When the majority of end users who  
are supposed to buy the service will not?

Okie, trick question. :)  You don't.

-- 
TTFN,
patrick

Delivery-date: Sun, 16 Apr 2006 07:19:23 +0000
Cc: shim6-wg <[email-masked]>, [email-masked], [email-masked], IETF Discussion <[email-masked]>, [email-masked], [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 09:17:52 +0200
To: "Patrick W. Gilmore" <[email-masked]>

On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote:

> Wow, Iljitsch, I have never lost so much respect so quickly for  
> someone who was not flaming a specific person or using profanity.   
> Congratulations.

Well, that's too bad. But several years of trying to get a scalable  
multihoming off the ground (flying to different meetings on my own  
dime) where first my ideas about PI aggregation are rejected within  
the IETF mostly without due consideration because it involves the  
taboo word "geography" only to see the next best thing being rejected  
by people who, as far as I can tell, lack a view of the big picture,  
is enough to make me lose my cool. Just a little.

> Back on topic, it is not just those 60 people - the "playground"  
> appears to overwhelmingly agree with their position.  I know I do.

Don't you think it's strange that the views within ARIN are so  
radically different than those within the IETF? Sure, inside the IETF  
there are also people who think PI in IPv6 won't be a problem, but  
it's not the majority (as far as I can tell) and certainly not  
anything close to 90%. Now the IETF process isn't perfect, as many  
things depend on whether people feel like actually doing something.  
But many of the best and the brightest in the IETF have been around  
for some time in multi6 and really looked at the problem. Many, if  
not most, of them concluded that we need something better than IPv4  
practices to make IPv6 last as long as we need it to last. Do you  
think all of them were wrong?

> I am sorry your technical arguments have not persuaded us in the  
> past.  But I would urge you to stick to those,

Stay tuned.

Delivery-date: Sun, 16 Apr 2006 04:11:00 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked], IETF Discussion <[email-masked]>, [email-masked], [email-masked]
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Sun, 16 Apr 2006 00:09:43 -0400
To: Iljitsch van Beijnum <[email-masked]>

On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote:

> On 14-apr-2006, at 16:57, Scott Leibrand wrote:
>
>> 60 voted in favor of moving forward with PI.  6 voted against.
>
> Wow, 10 to 1. Amazing.
>
> Even more amazing: 60 people who represent nobody but their own  
> paycheck get to blow up the internet.
>
> Where is ICANN when you need it? This little experiment in  
> playground democracy has to end before people get hurt.

Wow, Iljitsch, I have never lost so much respect so quickly for  
someone who was not flaming a specific person or using profanity.   
Congratulations.

Back on topic, it is not just those 60 people - the "playground"  
appears to overwhelmingly agree with their position.  I know I do.

I am sorry your technical arguments have not persuaded us in the  
past.  But I would urge you to stick to those, or at least consider  
why we remain unconvinced, rather than devolve into .. whatever that  
post was supposed to be.

-- 
TTFN,
patrick

Delivery-date: Fri, 14 Apr 2006 15:21:25 +0000
Cc: Gunter Van de Velde (gvandeve) <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: PI addressing in IPv6 advances in ARIN
Date: Fri, 14 Apr 2006 11:21:34 -0400
To: Iljitsch van Beijnum <[email-masked]>

On Apr 14, 2006, at 7:14 AM, Iljitsch van Beijnum wrote:

> While I'm in a nasty mood anyway, let me make the most of it...
>
> Would you people prune the god damn quotes already!!!!!!

It might be a good idea to stop cross posting to 3 lists while you  
are at it.

Regards
Marshall (who will send future replies to ppml only)

Delivery-date: Fri, 14 Apr 2006 15:15:33 +0000
Date: Fri, 14 Apr 2006 11:14:51 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: "Jason [email-masked]" <[email-masked]>,  Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked],  [email-masked], IETF Discussion <[email-masked]>,  [email-masked], [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum <[email-masked]> wrote:

> On 14-apr-2006, at 16:57, Scott Leibrand wrote:
>
> > 60 voted in favor of moving forward with PI.  6 voted against.
>
> Wow, 10 to 1. Amazing.
>
> Even more amazing: 60 people who represent nobody but their own
> paycheck get to blow up the internet.

Did you participate in the process?  Even if you can't justify travel to
Montreal, the PPML is wide open.

ARIN doesn't go solely by the vote in the room; they also consider whether
there was consensus on the PPML.

> Where is ICANN when you need it? This little experiment in playground
> democracy has to end before people get hurt.

I think the ARIN process is closer to the IETF's "rough consensus" process
than to "democracy".

If you think the PI policy ARIN passed will "blow up the internet", I
would encourage you to participate in drafting policy proposals to help
limit the impact of PI on the routing table.  Bear in mind that we didn't
approve an "IPv6 PI for everyone" policy precisely to avoid "blowing up
the Internet": instead we only extended existing IPv4 policy to IPv6.

As I've written before, I'm attempting to draft an ARIN policy proposal to
ensure PI addresses are assigned in a regular fashion instead of the
random chronological fashion we do now with IPv4.  As you seem to support
that, I would encourage you to help draft such a policy proposal and help
get people to support it.

-Scott

P.S. I don't think we need quite so much cross-posting as this...

Delivery-date: Fri, 14 Apr 2006 15:08:08 +0000
Cc: "Jason [email-masked]" <[email-masked]>, Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked], IETF Discussion <[email-masked]>, [email-masked], [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 17:07:26 +0200
To: Scott Leibrand <[email-masked]>

On 14-apr-2006, at 16:57, Scott Leibrand wrote:

> 60 voted in favor of moving forward with PI.  6 voted against.

Wow, 10 to 1. Amazing.

Even more amazing: 60 people who represent nobody but their own  
paycheck get to blow up the internet.

Where is ICANN when you need it? This little experiment in playground  
democracy has to end before people get hurt.

Delivery-date: Fri, 14 Apr 2006 14:58:12 +0000
Date: Fri, 14 Apr 2006 10:57:48 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: "Jason [email-masked]" <[email-masked]>,  Joe Abley <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

On 04/14/06 at 9:34am +0200, Iljitsch van Beijnum <[email-masked]> wrote:

> On 14-apr-2006, at 2:05, Jason Schiller ([email-masked]) wrote:
>
> > BTW, I was one of six people who voted against moving forward with PI.
>
> How many people voted in favor?

60 voted in favor of moving forward with PI.  6 voted against.

(I would've been the 61st, but couldn't attend in person.)

-Scott

Delivery-date: Fri, 14 Apr 2006 14:47:16 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 16:47:02 +0200
To: Marshall Eubanks <[email-masked]>

On 14-apr-2006, at 16:39, Marshall Eubanks wrote:

>> Actually it doesn't. It's very hard to qualify for a /22 so  
>> effectively this only helps Big Content. The issue

> No, it is not. (Speaking as someone who has helped people get one.)

Yes, it is for many organizations. (Speaking as someone who has  
helped people get prefixes of various sizes.)

Delivery-date: Fri, 14 Apr 2006 14:41:47 +0000
Cc: "Craig Huegen \(chuegen\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: PI addressing in IPv6 advances in ARIN
Date: Fri, 14 Apr 2006 16:41:10 +0200
To: "Durand, Alain" <[email-masked]>

On 14-apr-2006, at 16:02, Durand, Alain wrote:

>> Maybe I'm being overly simplistic, but the policy can set a
>> recovery timeframe in its allocation of PI space to end users
>> and the market forces can drive the recovery based on the
>> impact to the infrastructure.
>> If only a few hundred prefixes are handed out, it might not
>> be enough of a problem to force recovery.

> One could argue that if we are only talking about a few hundred
> prefixes,
> Why do we care reclaiming them?

If the number of prefixes becomes large enough to be problematic,  
reclaiming those to solve these problems isn't going to work. For one  
thing, it's likely that such problems won't be experienced to the  
same degree by different people: people with a few large routers (and  
deep pockets) will be in a much better position than people with a  
larger number of smaller routers (and less money). Also, policy  
development is done regionally while the results are suffered  
globally. But even discounting all of that, if ARIN were to decide  
that the prefixes must be revoked, it will take a significant amount  
of time before that actually happens. It gets worse when people start  
to sue.

So in practice the only thing that can happen is that if the problem  
is severe (i.e., that 51% of all people in the (rich) ARIN region  
feel the pain) the policy is changed so that no _new_ prefixes of  
this type are given out, and then we have to wait for the increase in  
router performance over time to make the problem disappear.

If it gets really bad a quick "ipv6 prefix-list no-v6-pi deny ::/0 ge  
48" will clean up the routing table and a timeout or two later you're  
back on IPv4 when trying to reach the holders of these PI blocks.

Delivery-date: Fri, 14 Apr 2006 14:39:40 +0000
Cc: Jason Schiller ([email-masked]) <[email-masked]>, Joe Abley <[email-masked]>, shim6-wg <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 10:39:41 -0400
To: Iljitsch van Beijnum <[email-masked]>

On Apr 14, 2006, at 3:34 AM, Iljitsch van Beijnum wrote:

> On 14-apr-2006, at 2:05, Jason Schiller ([email-masked]) wrote:
>
>> I'd like to point out that if people think that PI (and placing 1 or
>> more routes in the global Internet routing table) is an acceptable
>> solution to multi-homing, then it is also likely that more  
>> specifics of PA
>> space to support multi-homing is also acceptable, and likely to  
>> happen.
>
>> This removes the fact that few people would be able to multi-home  
>> in the
>> traditional sense.
>
> Actually it doesn't. It's very hard to qualify for a /22 so  
> effectively this only helps Big Content. The issue

No, it is not. (Speaking as someone who has helped people get one.)

Regards
Marshall

> of smaller ISPs or whole sale transit carriers that don't give out  
> address space to their customers because those all have PA isn't  
> addressed here.
>
> But it completely changes the game: why spend time on deploying  
> shim6 if you can round up your IPv4 needs to get to a /22 or lobby  
> for reducing the /22 requirement?
>
>> So there are only two questions:
>
>> 1. Is there sufficent need to continue shim6 for a no-frills easy
>> multi-homing solution for consumer and small business customers  
>> that can't
>> or won't support BGP?
>
>> 2. Are people concerned with the long term implacations of de- 
>> aggrgegation
>> for multi-homing, and if so, then should we pursue a protocol  
>> solution
>> that has full support for TE in an effort to replace de- 
>> aggrgegation as a
>> solution and halt (or possibly reverse) the growth of the routing  
>> table?
>
> Let me add a third question: will shim6 be deployable when people  
> can get PI?
>
> Maybe shim6 can still do some good but we really need to rethink  
> our goals here. I was uncomfortable with moving fast and only  
> implementing bare bones mechanisms before, and even more so now. We  
> should slow down and get it right the first try because if there is  
> a place for shim6 in a world with IPv6 PI, that place is for a GOOD  
> shim6 solution that solves the problem well, something that kinda  
> works just to get something out the door isn't good enough and  
> there won't be a second chance to come up with an improved version.
>
>> BTW, I was one of six people who voted against moving forward with  
>> PI.
>
> How many people voted in favor?
>

Delivery-date: Fri, 14 Apr 2006 12:22:54 +0000
Date: Fri, 14 Apr 2006 14:22:27 +0200
Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN
From: JORDI PALET MARTINEZ <[email-masked]>
To: "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

Hi all,

My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE
and the rest of the regions, trying to get a consensus for a "global" policy
on this, but as this thread is being followed up in several mail exploders,
to avoid a long cross-posting, I think it will be better to start some
discussion already in a mailing list which is global, and actually I think
we have the right one ... [email-masked]

So, if you aren't subscribed in the [email-masked], and you're
interested in this thread, please subscribe at
http://mailman.apnic.net/mailman/listinfo/global-v6

If you're late because the Eastern, the archives are also available at
http://www.apnic.net/mailing-lists/global-v6/

Regards,
Jordi

> De: JORDI PALET MARTINEZ <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 14 Apr 2006 13:39:07 +0200
> Para: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Conversación: [ppml] PI addressing in IPv6 advances in ARIN
> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
> 
> Hi Owen,
> 
> You said it: If somebody find the good solution, it will be attractive to
> the people to go for it. Otherwise, you always have the chance to become an
> LIR. My proposal actually is already considering this point and a way to
> avoid a need for renumbering if that happens.
> 
> I just want to make sure that we have a way-out if it becomes necessary, but
> avoid a showstopper now. I think is it possible.
> 
> I don't have a technical solution yet (and agree with your views on this in
> the email below in general), but I'm confident we will have. If it will take
> 4 years from now, or just 2, who knows, so my proposal is ensuring that we
> have those 4 years+3 for allowing the people either to return the block, or
> become an LIR and avoid renumbering an any changes in their network.
> 
> By the way, it may happen, and I'm hoping so, that the technical solution
> don't make necessary to return the PI block anymore, and in that case, we
> will be even able to remove at that time the "temporarily" point in the
> policy (if it becomes accepted).
> 
> Regards,
> Jordi
> 
> 
> 
> 
>> De: Owen DeLong <[email-masked]>
>> Responder a: <[email-masked]>
>> Fecha: Fri, 14 Apr 2006 03:48:34 -0700
>> Para: <[email-masked]>, "[email-masked]"
>> <[email-masked]>,
>> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>> 
>> 
>> 
>> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ
>> <[email-masked]> wrote:
>> 
>> [snip]
>>> However, I want to balance this with the medium-long term implications
>>> created in the routing table and with the time needed to build and deploy
>>> a better technical solution (or several) which is accepted by the
>>> community.
>>> 
>> I think we first need to define what we consider a solution... See below.
>> 
>>> So my proposal basically is about having PI now everywhere (once ARIN
>>> adopt it, is unfair not having it in other regions), but those PI
>>> allocations for multihoming should be temporary and those address blocks
>>> returned to the RIRs some time (lets say 3 years) after the new technical
>>> solution is declared as a valid one.
>>> 
>> I would not actually support this idea.  The whole point of having PI
>> space is to have the addresses for a long-term.  Having a timeframe for
>> return would simply restore the same barrier to entry that existed
>> prior to passing the policy.
>> 
>> Other RIRs are free to implement whatever v6 PI policy they feel is
>> appropriate for their region.  I would support a globally standardized
>> v6 PI policy along the lines of ARIN 2005-1.
>> 
>> However, I would like to argue that if the new technical solution will
>> benefit from the return of this address space, it is most likely not
>> truly a solution, but, instead, another clever hack piled on top of
>> the existing set of hacks.
>> 
>> I suppose if someone found the magic bullet to make geotopological
>> addressing really work, that might qualify.  However, I have very low
>> expectations in that area.
>> 
>> Absent that, any true solution will involve making the size of the routing
>> table independent of the number of PI (or even PA) blocks issued by
>> the RIRs or will make the size of the routing table practically
>> irrelevant.
>> 
>> I know this isn't the easy solution, but, we need to look long and
>> hard at the way we do things.  I think that solving these problems
>> is going to require a significant paradigm shift.  Assuming that we
>> can use IP addresses for both end system identification and for
>> routing topology indicators is how we created this problem.  I don't
>> see solving it without breaking that assumption, at least at the
>> interdomain level.
>> 
>> 
>>> At this way, on the long-run, we will not have routing table implications,
>>> but we allow now the people that want to move ahead only if they have a
>>> multihoming solution doing so.
>>> 
>> If you think there is a possible solution (a real solution, not just
>> a hack that postpones the inevitable at the expense of usability
>> like CIDR did), then I'd like to hear what you are thinking.
>> 
>>> This 3-years time for getting a multihoming network back to the new
>>> technical solution (once adopted) is enough time, I think (it could be
>>> changed to 5 years if needed, or whatever), so nobody today see the
>>> temporarily of the proposal as a showstopper to go for it now.
>>> 
>> I think you underestimate the momentum and requirements of the modern
>> enterprise if you believe that to be true.  Any capability available
>> in v4 that is not available on at least equal or better terms in v6
>> is a deterrent to v6 deployment.
>> 
>> The ability to get permanent addresses which do not have to be returned
>> when you switch providers or renumbered on a schedule determined by
>> some external organization is a major example of such a capability.
>> 
>> Owen
>> 
>> 
>> -- 
>> If it wasn't crypto-signed, it probably didn't come from me.
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Fri, 14 Apr 2006 12:08:37 +0000
Date: Fri, 14 Apr 2006 14:08:05 +0200
Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN
From: JORDI PALET MARTINEZ <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, IPv6 in Africa <[email-masked]>, <[email-masked]>, <[email-masked]>
Reply-To: [email-masked]

Hi all,

My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE
and the rest of the regions, trying to get a consensus for a "global" policy
on this, but as this thread is being followed up in several mail exploders,
to avoid a long cross-posting, I think it will be better to start some
discussion already in a mailing list which is global, and actually I think
we have the right one ... [email-masked]

So, if you aren't subscribed in the [email-masked], and you're
interested in this thread, please subscribe at
http://mailman.apnic.net/mailman/listinfo/global-v6

If you're late because the Eastern, the archives are also available at
http://www.apnic.net/mailing-lists/global-v6/

Regards,
Jordi

> De: JORDI PALET MARTINEZ <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 14 Apr 2006 13:39:07 +0200
> Para: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Conversación: [ppml] PI addressing in IPv6 advances in ARIN
> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
> 
> Hi Owen,
> 
> You said it: If somebody find the good solution, it will be attractive to
> the people to go for it. Otherwise, you always have the chance to become an
> LIR. My proposal actually is already considering this point and a way to
> avoid a need for renumbering if that happens.
> 
> I just want to make sure that we have a way-out if it becomes necessary, but
> avoid a showstopper now. I think is it possible.
> 
> I don't have a technical solution yet (and agree with your views on this in
> the email below in general), but I'm confident we will have. If it will take
> 4 years from now, or just 2, who knows, so my proposal is ensuring that we
> have those 4 years+3 for allowing the people either to return the block, or
> become an LIR and avoid renumbering an any changes in their network.
> 
> By the way, it may happen, and I'm hoping so, that the technical solution
> don't make necessary to return the PI block anymore, and in that case, we
> will be even able to remove at that time the "temporarily" point in the
> policy (if it becomes accepted).
> 
> Regards,
> Jordi
> 
> 
> 
> 
>> De: Owen DeLong <[email-masked]>
>> Responder a: <[email-masked]>
>> Fecha: Fri, 14 Apr 2006 03:48:34 -0700
>> Para: <[email-masked]>, "[email-masked]"
>> <[email-masked]>,
>> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>> 
>> 
>> 
>> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ
>> <[email-masked]> wrote:
>> 
>> [snip]
>>> However, I want to balance this with the medium-long term implications
>>> created in the routing table and with the time needed to build and deploy
>>> a better technical solution (or several) which is accepted by the
>>> community.
>>> 
>> I think we first need to define what we consider a solution... See below.
>> 
>>> So my proposal basically is about having PI now everywhere (once ARIN
>>> adopt it, is unfair not having it in other regions), but those PI
>>> allocations for multihoming should be temporary and those address blocks
>>> returned to the RIRs some time (lets say 3 years) after the new technical
>>> solution is declared as a valid one.
>>> 
>> I would not actually support this idea.  The whole point of having PI
>> space is to have the addresses for a long-term.  Having a timeframe for
>> return would simply restore the same barrier to entry that existed
>> prior to passing the policy.
>> 
>> Other RIRs are free to implement whatever v6 PI policy they feel is
>> appropriate for their region.  I would support a globally standardized
>> v6 PI policy along the lines of ARIN 2005-1.
>> 
>> However, I would like to argue that if the new technical solution will
>> benefit from the return of this address space, it is most likely not
>> truly a solution, but, instead, another clever hack piled on top of
>> the existing set of hacks.
>> 
>> I suppose if someone found the magic bullet to make geotopological
>> addressing really work, that might qualify.  However, I have very low
>> expectations in that area.
>> 
>> Absent that, any true solution will involve making the size of the routing
>> table independent of the number of PI (or even PA) blocks issued by
>> the RIRs or will make the size of the routing table practically
>> irrelevant.
>> 
>> I know this isn't the easy solution, but, we need to look long and
>> hard at the way we do things.  I think that solving these problems
>> is going to require a significant paradigm shift.  Assuming that we
>> can use IP addresses for both end system identification and for
>> routing topology indicators is how we created this problem.  I don't
>> see solving it without breaking that assumption, at least at the
>> interdomain level.
>> 
>> 
>>> At this way, on the long-run, we will not have routing table implications,
>>> but we allow now the people that want to move ahead only if they have a
>>> multihoming solution doing so.
>>> 
>> If you think there is a possible solution (a real solution, not just
>> a hack that postpones the inevitable at the expense of usability
>> like CIDR did), then I'd like to hear what you are thinking.
>> 
>>> This 3-years time for getting a multihoming network back to the new
>>> technical solution (once adopted) is enough time, I think (it could be
>>> changed to 5 years if needed, or whatever), so nobody today see the
>>> temporarily of the proposal as a showstopper to go for it now.
>>> 
>> I think you underestimate the momentum and requirements of the modern
>> enterprise if you believe that to be true.  Any capability available
>> in v4 that is not available on at least equal or better terms in v6
>> is a deterrent to v6 deployment.
>> 
>> The ability to get permanent addresses which do not have to be returned
>> when you switch providers or renumbered on a schedule determined by
>> some external organization is a major example of such a capability.
>> 
>> Owen
>> 
>> 
>> -- 
>> If it wasn't crypto-signed, it probably didn't come from me.
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Fri, 14 Apr 2006 12:07:01 +0000
Cc: "shim6-wg" <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 14:06:43 +0200
To: Per Heldal <[email-masked]>

On 14-apr-2006, at 13:49, Per Heldal wrote:

>>> Geo-aggregation doesn't work in a competitive market. It would  
>>> require
>>> new routing-technology to do so, and thus fall in the same  
>>> category as
>>> shim6.

>> Well obviously you don't know what you're talking about (not
>> apologizing for my crankiness, btw) or we wouldn't be having this
>> discussion in the first place.

> The alternative to new technology is to break the business-model for
> transit. Endless treads on this issue over 10 or more years have  
> mainly
> concluded that with existing technology transit providers either  
> have to
> provide equal connectivity to everyone in a region (customer as
> non-customer), or eliminate the gain from geotop by announcing
> more-specific routes. This problem currently has no technical solution
> ... hence something else is needed.

The discussions that you elude to were never very informed because  
nobody else ever bothered to work out the details in a draft. I think  
it can be done and here you can read how:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

> IPv6 without PI, shim6 or some other alternative won't fly.

Well, shim6 is moving along at a reasonable speed these days. And as  
I said before, it's not like people are adopting IPv6 en masse at  
this time. Now some people say it's lack of an IPv6 multihoming  
solution that holds IPv6 deployment back but I don't believe that for  
one second as multihoming in IPv4 isn't all that common to begin with  
and the idea that you need two of something when you don't even use  
one is a bit strange.

> However, an alternative is to stop V6 deployment until the supporting
> technology is ready ... if you can hold back the floodgates of hype
> driving it.

I'm doing my bit with regard to the latter, and I don't think any  
holding back is required, there is still SO much to do: IPv6 software  
SOHO routers, ISP networks,  content networks, applications...

> Turning to reality; I haven't seen anything indicating that practical
> limitations have come closer in recent years. In fact, the average
> router today has more headroom than its ancestors back in '98 or '99.

The difference being that in those days, it was still feasible to do  
full routing in a fairly small network. These days, a router that is  
both fast enough to forward at the required speed (at least close to  
a gigabit per second) and has enough memory and FIB table space to do  
full routing is too expensive for a small network so they use Quagga  
or just don't bother.

Delivery-date: Fri, 14 Apr 2006 11:55:08 +0000
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN
Date: Fri, 14 Apr 2006 13:54:56 +0200
To: [email-masked]

On 14-apr-2006, at 13:39, JORDI PALET MARTINEZ wrote:

> my proposal is ensuring that we
> have those 4 years+3 for allowing the people either to return the  
> block, or
> become an LIR and avoid renumbering an any changes in their network.

I don't see the logic of an end-user organization becoming a LIR in  
the sense that they give out address space to other end-user  
organizations. And even if they did, a /48 or even a reserved /44  
(why not give them the /44 right away then, at least that saves us  
from accepting /48s which is dangerous because of potentially  
deaggregated /32s and we have IPv6 addresses aplenty) isn't big  
enough to be a LIR without obtaining a new address block.

> By the way, it may happen, and I'm hoping so, that the technical  
> solution
> don't make necessary to return the PI block anymore, and in that  
> case, we
> will be even able to remove at that time the "temporarily" point in  
> the
> policy (if it becomes accepted).

If the PI blocks are given out according to a geographic addressing  
plan we leave the door open for geographic aggregation in the future.  
I know few people believe in this today but if we're going to have PI  
anyway, giving out those prefixes geographically doesn't do any harm  
but it allows for future developments.

Delivery-date: Fri, 14 Apr 2006 11:50:51 +0000
From: "Per Heldal" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 13:49:58 +0200

On Fri, 14 Apr 2006 13:12:42 +0200, "Iljitsch van Beijnum"
<[email-masked]> said:
> On 14-apr-2006, at 12:42, Per Heldal wrote:
> 
> >> An alternative would be to give the prefixes out based on geography,
> >> so there is at least a chance that we get to aggregate them
> >> geographically in the future. But despite the fact that doing this is
> >> entirely risk-free (geo PI without geo aggregation is no worse than
> >> regular PI) people want proof that it works first, while at the same
> >> for deploying regular PI the burden of proof is reversed so it's
> >> allowed now despite very good indications (but not hard proof) that
> >> it will be problematic in the future.
> 
> > Geo-aggregation doesn't work in a competitive market. It would require
> > new routing-technology to do so, and thus fall in the same category as
> > shim6.
> 
> Well obviously you don't know what you're talking about (not  
> apologizing for my crankiness, btw) or we wouldn't be having this  
> discussion in the first place.

The alternative to new technology is to break the business-model for
transit. Endless treads on this issue over 10 or more years have mainly
concluded that with existing technology transit providers either have to
provide equal connectivity to everyone in a region (customer as
non-customer), or eliminate the gain from geotop by announcing
more-specific routes. This problem currently has no technical solution
... hence something else is needed.

[snip]
> 
> The challenge for the community as a whole is to accept limitations  
> rather than ignore them and hope the problems that are created by  
> behaving that way will magically disappear.

It's not the first time in history researchers fail to meet deadlines or
otherwise have to accept that society moves on given whatever resources
are available at the time. 

> 
> The IETF been talking about scalable routing = scalable multihoming  
> for at least a decade and it's entirely clear that there is no pain- 
> free solution that allows all the current benefits without incurring  
> any of the bad side effects. Ignore this lesson at your peril.

In some distant history (pre 1990) the IETF would just have moved on
making a practical solution based on actual requirements. Now it's about
to become a second ITU,  hampered by procedures and unable to make a
decision in any issue where there is more than one opinion. 

> 
> >> IPv6 is really just repeating the same mistake with longer addresses.
> 
> > I didn't say it's a perfect solution, but we're not living in a  
> > perfect
> > world.
> 
> Oh, my mistake. Obviously because the world is imperfect it's ok to  
> do things we know are dumb beforehand.
> 
> > If we're unable to come up with a product the market wants we
> > have to accept that the market makes the most of what it's got
> > regardless of what we may think about it.
> 
> Yeah, ain't capitalism grand. To quote 10cc:
> 
> To do the Wall Street Shuffle
> Let your money hustle
> Bet you'd sell your mother
> You can buy another

This isn't necessarily about money. To some it's about reality vs
fantasy. 

IPv6 without PI, shim6 or some other alternative won't fly.

However, an alternative is to stop V6 deployment until the supporting
technology is ready ... if you can hold back the floodgates of hype
driving it.

> 
> > PS! I believe the probability of something entirely new replacing
> > IPv<anything> is much greater than the probability of the internet
> > falling apart due to its growth.
> 
> Say hi to the easter bunny if you run into it this weekend, by the  
> way. Belief has no place in engineering. But it doesn't matter one  
> way or the other, as I'm sure the ARIN constituents will reject it if  
> it's really this great.

Turning to reality; I haven't seen anything indicating that practical
limitations have come closer in recent years. In fact, the average
router today has more headroom than its ancestors back in '98 or '99.

Demonstrate how to implement scalable shim6 with traffic engineering in
a network with 10k hosts of various types this month, and I'll stop
talking about PI.

//per
-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Fri, 14 Apr 2006 11:39:44 +0000
Date: Fri, 14 Apr 2006 13:39:07 +0200
Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN
From: JORDI PALET MARTINEZ <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

Hi Owen,

You said it: If somebody find the good solution, it will be attractive to
the people to go for it. Otherwise, you always have the chance to become an
LIR. My proposal actually is already considering this point and a way to
avoid a need for renumbering if that happens.

I just want to make sure that we have a way-out if it becomes necessary, but
avoid a showstopper now. I think is it possible.

I don't have a technical solution yet (and agree with your views on this in
the email below in general), but I'm confident we will have. If it will take
4 years from now, or just 2, who knows, so my proposal is ensuring that we
have those 4 years+3 for allowing the people either to return the block, or
become an LIR and avoid renumbering an any changes in their network.

By the way, it may happen, and I'm hoping so, that the technical solution
don't make necessary to return the PI block anymore, and in that case, we
will be even able to remove at that time the "temporarily" point in the
policy (if it becomes accepted).

Regards,
Jordi

> De: Owen DeLong <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 14 Apr 2006 03:48:34 -0700
> Para: <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
> 
> 
> 
> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ
> <[email-masked]> wrote:
> 
> [snip]
>> However, I want to balance this with the medium-long term implications
>> created in the routing table and with the time needed to build and deploy
>> a better technical solution (or several) which is accepted by the
>> community.
>> 
> I think we first need to define what we consider a solution... See below.
> 
>> So my proposal basically is about having PI now everywhere (once ARIN
>> adopt it, is unfair not having it in other regions), but those PI
>> allocations for multihoming should be temporary and those address blocks
>> returned to the RIRs some time (lets say 3 years) after the new technical
>> solution is declared as a valid one.
>> 
> I would not actually support this idea.  The whole point of having PI
> space is to have the addresses for a long-term.  Having a timeframe for
> return would simply restore the same barrier to entry that existed
> prior to passing the policy.
> 
> Other RIRs are free to implement whatever v6 PI policy they feel is
> appropriate for their region.  I would support a globally standardized
> v6 PI policy along the lines of ARIN 2005-1.
> 
> However, I would like to argue that if the new technical solution will
> benefit from the return of this address space, it is most likely not
> truly a solution, but, instead, another clever hack piled on top of
> the existing set of hacks.
> 
> I suppose if someone found the magic bullet to make geotopological
> addressing really work, that might qualify.  However, I have very low
> expectations in that area.
> 
> Absent that, any true solution will involve making the size of the routing
> table independent of the number of PI (or even PA) blocks issued by
> the RIRs or will make the size of the routing table practically
> irrelevant.
> 
> I know this isn't the easy solution, but, we need to look long and
> hard at the way we do things.  I think that solving these problems
> is going to require a significant paradigm shift.  Assuming that we
> can use IP addresses for both end system identification and for
> routing topology indicators is how we created this problem.  I don't
> see solving it without breaking that assumption, at least at the
> interdomain level.
> 
> 
>> At this way, on the long-run, we will not have routing table implications,
>> but we allow now the people that want to move ahead only if they have a
>> multihoming solution doing so.
>> 
> If you think there is a possible solution (a real solution, not just
> a hack that postpones the inevitable at the expense of usability
> like CIDR did), then I'd like to hear what you are thinking.
> 
>> This 3-years time for getting a multihoming network back to the new
>> technical solution (once adopted) is enough time, I think (it could be
>> changed to 5 years if needed, or whatever), so nobody today see the
>> temporarily of the proposal as a showstopper to go for it now.
>> 
> I think you underestimate the momentum and requirements of the modern
> enterprise if you believe that to be true.  Any capability available
> in v4 that is not available on at least equal or better terms in v6
> is a deterrent to v6 deployment.
> 
> The ability to get permanent addresses which do not have to be returned
> when you switch providers or renumbered on a schedule determined by
> some external organization is a major example of such a capability.
> 
> Owen
> 
> 
> -- 
> If it wasn't crypto-signed, it probably didn't come from me.

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Fri, 14 Apr 2006 11:25:10 +0000
Date: Fri, 14 Apr 2006 13:24:31 +0200
Subject: Re: PI addressing in IPv6 advances in ARIN
From: JORDI PALET MARTINEZ <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

See below.

Regards,
Jordi

> De: "Gunter Van de Velde (gvandeve)" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 14 Apr 2006 12:43:31 +0200
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Asunto: Re: PI addressing in IPv6 advances in ARIN
> 
> Hi Jordi,
> 
> Please see inline.
> 
> At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote:
>> Hi Jim,
>> 
>> Not sure if I got your question correctly, but let me try to explain my
>> view.
>> 
>> I understand the position of the people that say they need PI today,
>> especially because not having it may be hurting the advancement of the IPv6
>> deployment.
>> 
>> However, I want to balance this with the medium-long term implications
>> created in the routing table and with the time needed to build and deploy a
>> better technical solution (or several) which is accepted by the community.
>> 
>> So my proposal basically is about having PI now everywhere (once ARIN adopt
>> it, is unfair not having it in other regions), but those PI allocations for
>> multihoming should be temporary and those address blocks returned to the
>> RIRs some time (lets say 3 years) after the new technical solution is
>> declared as a valid one.
> 
> That will never happen i suppose... once there is PI space out there, then
> it will be there forever.... the discussion in 2 a 3 years will be the same
> as now because
> Network Management staff just don't like to renumber their infrastructures
> (and that is
> for valid reasons), and this is even more valid when speaking about the very
> large enterprise organizations. If PI is accepted now, then i suppose it
> will be out there
> forever and ever.

Precisely, writing it in the policy will make clear what is not forever.

Even if the policy don't say it is temporary, it can be changed at any time.
I think is more fair to tell it clearly since the time time the policy is
accepted.

By the way, something else that I've in my proposal is clarifying that if a
use of this policy don't want to go to the technical solution later on, he
has, of course, the chance to become an LIR at that time and avoid
renumbering (of course, needs to qualify for LIR).

> 
> When PI space is out there then i wonder who of these organizations would
> actually
> still be interested in a shim solution and further development may result
> in an academical
> effort.

I'm not necessarily talking about shim or only about shim. I hope there will
be solutions that will make attractive going for this change.

> 
> Brgds,
> G/
> 
>> At this way, on the long-run, we will not have routing table implications,
>> but we allow now the people that want to move ahead only if they have a
>> multihoming solution doing so.
>> 
>> This 3-years time for getting a multihoming network back to the new
>> technical solution (once adopted) is enough time, I think (it could be
>> changed to 5 years if needed, or whatever), so nobody today see the
>> temporarily of the proposal as a showstopper to go for it now.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: "Bound, Jim" <[email-masked]>
>>> Responder a: <[email-masked]>
>>> Fecha: Fri, 14 Apr 2006 03:11:58 -0400
>>> Para: <[email-masked]>, <[email-masked]>
>>> Conversación: PI addressing in IPv6 advances in ARIN
>>> Asunto: RE: PI addressing in IPv6 advances in ARIN
>>> 
>>> Jordi, why this will work as is for now?
>>> /jim
>>> 
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
>>>> Sent: Thursday, April 13, 2006 5:28 PM
>>>> To: [email-masked]
>>>> Subject: Re: PI addressing in IPv6 advances in ARIN
>>>> 
>>>> Hi Thomas, all,
>>>> 
>>>> During my fly-back from Montreal, I've worked in a proposal
>>>> and I'm talking to folks in each RIR/region, with the idea to
>>>> submit it to all them as a kind of (if possible), global policy.
>>>> 
>>>> The idea is based on the comments that I did at the mic
>>>> during the ARIN meeting.
>>>> 
>>>> I will try to get this submitted next Monday/Tuesday and get
>>>> ready for a formal presentation during the next RIPE meeting
>>>> at Istanbul (following week).
>>>> 
>>>> Regards,
>>>> Jordi
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> De: Thomas Narten <[email-masked]>
>>>>> Responder a: <[email-masked]>
>>>>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400
>>>>> Para: "Gunter Van de Velde (gvandeve)" <[email-masked]>
>>>>> CC: "[email-masked]" <[email-masked]>
>>>>> Asunto: Re: PI addressing in IPv6 advances in ARIN
>>>>> 
>>>>>> What would be the prefix allocation per organization?
>>>>> 
>>>>> /48, though can be larger in some cases. Watch for the revised
>>>>> proposal that gets last called for details.
>>>>> 
>>>>>> (Me being in Europe and not attending ARIN sessions)
>>>>> 
>>>>> Note: none of the other RIRs have such a policy in place
>>>> today, though
>>>>> I wouldn't be surprised if they now followup with proposals
>>>> of their
>>>>> own (though someone has to do it).
>>>>> 
>>>>>> Has there been study on the # of organizations going for
>>>> this and if
>>>>>> the impact will be more significant then more's law on technology
>>>>>> enhancement?
>>>>> 
>>>>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today,"
>>>>> "looking at the impact of the current IPv4 policies, the
>>>> number of PI
>>>>> assignments is only on the 100s per year", and "we can update the
>>>>> policy if things get problematical".
>>>>> 
>>>>> Thomas
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> **********************************************
>>>> The IPv6 Portal: http://www.ipv6tf.org
>>>> 
>>>> Barcelona 2005 Global IPv6 Summit
>>>> Slides available at:
>>>> http://www.ipv6-es.com
>>>> 
>>>> This electronic message contains information which may be
>>>> privileged or confidential. The information is intended to be
>>>> for the use of the individual(s) named above. If you are not
>>>> the intended recipient be aware that any disclosure, copying,
>>>> distribution or use of the contents of this information,
>>>> including attached files, is prohibited.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Fri, 14 Apr 2006 11:15:27 +0000
Cc: [email-masked], "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: PI addressing in IPv6 advances in ARIN
Date: Fri, 14 Apr 2006 13:14:49 +0200
To: Gunter Van de Velde (gvandeve) <[email-masked]>

While I'm in a nasty mood anyway, let me make the most of it...

Would you people prune the god damn quotes already!!!!!!

On 14-apr-2006, at 12:43, Gunter Van de Velde (gvandeve) wrote:

> Hi Jordi,
>
> Please see inline.
>
> At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote:
>> Hi Jim,
>>
>> Not sure if I got your question correctly, but let me try to  
>> explain my
>> view.
>>
>> I understand the position of the people that say they need PI today,
>> especially because not having it may be hurting the advancement of  
>> the IPv6
>> deployment.
>>
>> However, I want to balance this with the medium-long term  
>> implications
>> created in the routing table and with the time needed to build and  
>> deploy a
>> better technical solution (or several) which is accepted by the  
>> community.
>>
>> So my proposal basically is about having PI now everywhere (once  
>> ARIN adopt
>> it, is unfair not having it in other regions), but those PI  
>> allocations for
>> multihoming should be temporary and those address blocks returned  
>> to the
>> RIRs some time (lets say 3 years) after the new technical solution is
>> declared as a valid one.
>
> That will never happen i suppose... once there is PI space out  
> there, then
> it will be there forever.... the discussion in 2 a 3 years will be  
> the same as now because
> Network Management staff just don't like to renumber their  
> infrastructures (and that is
> for valid reasons), and this is even more valid when speaking about  
> the very
> large enterprise organizations. If PI is accepted now, then i  
> suppose it will be out there
> forever and ever.
>
> When PI space is out there then i wonder who of these organizations  
> would actually
> still be interested in a shim solution and further development may  
> result in an academical
> effort.
>
> Brgds,
> G/
>
>> At this way, on the long-run, we will not have routing table  
>> implications,
>> but we allow now the people that want to move ahead only if they  
>> have a
>> multihoming solution doing so.
>>
>> This 3-years time for getting a multihoming network back to the new
>> technical solution (once adopted) is enough time, I think (it  
>> could be
>> changed to 5 years if needed, or whatever), so nobody today see the
>> temporarily of the proposal as a showstopper to go for it now.
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>> > De: "Bound, Jim" <[email-masked]>
>> > Responder a: <[email-masked]>
>> > Fecha: Fri, 14 Apr 2006 03:11:58 -0400
>> > Para: <[email-masked]>, <[email-masked]>
>> > Conversación: PI addressing in IPv6 advances in ARIN
>> > Asunto: RE: PI addressing in IPv6 advances in ARIN
>> >
>> > Jordi, why this will work as is for now?
>> > /jim
>> >
>> >> -----Original Message-----
>> >> From: [email-masked]
>> >> [mailto:[email-masked]] On Behalf Of JORDI PALET  
>> MARTINEZ
>> >> Sent: Thursday, April 13, 2006 5:28 PM
>> >> To: [email-masked]
>> >> Subject: Re: PI addressing in IPv6 advances in ARIN
>> >>
>> >> Hi Thomas, all,
>> >>
>> >> During my fly-back from Montreal, I've worked in a proposal
>> >> and I'm talking to folks in each RIR/region, with the idea to
>> >> submit it to all them as a kind of (if possible), global policy.
>> >>
>> >> The idea is based on the comments that I did at the mic
>> >> during the ARIN meeting.
>> >>
>> >> I will try to get this submitted next Monday/Tuesday and get
>> >> ready for a formal presentation during the next RIPE meeting
>> >> at Istanbul (following week).
>> >>
>> >> Regards,
>> >> Jordi
>> >>
>> >>
>> >>
>> >>
>> >>> De: Thomas Narten <[email-masked]>
>> >>> Responder a: <[email-masked]>
>> >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400
>> >>> Para: "Gunter Van de Velde (gvandeve)" <[email-masked]>
>> >>> CC: "[email-masked]" <[email-masked]>
>> >>> Asunto: Re: PI addressing in IPv6 advances in ARIN
>> >>>
>> >>>> What would be the prefix allocation per organization?
>> >>>
>> >>> /48, though can be larger in some cases. Watch for the revised
>> >>> proposal that gets last called for details.
>> >>>
>> >>>> (Me being in Europe and not attending ARIN sessions)
>> >>>
>> >>> Note: none of the other RIRs have such a policy in place
>> >> today, though
>> >>> I wouldn't be surprised if they now followup with proposals
>> >> of their
>> >>> own (though someone has to do it).
>> >>>
>> >>>> Has there been study on the # of organizations going for
>> >> this and if
>> >>>> the impact will be more significant then more's law on  
>> technology
>> >>>> enhancement?
>> >>>
>> >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted  
>> today,"
>> >>> "looking at the impact of the current IPv4 policies, the
>> >> number of PI
>> >>> assignments is only on the 100s per year", and "we can update the
>> >>> policy if things get problematical".
>> >>>
>> >>> Thomas
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> **********************************************
>> >> The IPv6 Portal: http://www.ipv6tf.org
>> >>
>> >> Barcelona 2005 Global IPv6 Summit
>> >> Slides available at:
>> >> http://www.ipv6-es.com
>> >>
>> >> This electronic message contains information which may be
>> >> privileged or confidential. The information is intended to be
>> >> for the use of the individual(s) named above. If you are not
>> >> the intended recipient be aware that any disclosure, copying,
>> >> distribution or use of the contents of this information,
>> >> including attached files, is prohibited.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be  
>> privileged or confidential. The information is intended to be for  
>> the use of the individual(s) named above. If you are not the  
>> intended recipient be aware that any disclosure, copying,  
>> distribution or use of the contents of this information, including  
>> attached files, is prohibited.
>
>

-- 
I've written another book! http://www.runningipv6.net/

Delivery-date: Fri, 14 Apr 2006 11:13:18 +0000
Cc: "shim6-wg" <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 13:12:42 +0200
To: Per Heldal <[email-masked]>

On 14-apr-2006, at 12:42, Per Heldal wrote:

>> An alternative would be to give the prefixes out based on geography,
>> so there is at least a chance that we get to aggregate them
>> geographically in the future. But despite the fact that doing this is
>> entirely risk-free (geo PI without geo aggregation is no worse than
>> regular PI) people want proof that it works first, while at the same
>> for deploying regular PI the burden of proof is reversed so it's
>> allowed now despite very good indications (but not hard proof) that
>> it will be problematic in the future.

> Geo-aggregation doesn't work in a competitive market. It would require
> new routing-technology to do so, and thus fall in the same category as
> shim6.

Well obviously you don't know what you're talking about (not  
apologizing for my crankiness, btw) or we wouldn't be having this  
discussion in the first place.

But even if geo aggregation requires new routing technology, which is  
not the case, then we should be giving out geo PI prefixes rather  
than regular PI prefixes because by the time the "required" new  
routing technology becomes available, it can be deployed on existing  
prefixes rather than only on new ones.

> The challenge for the technical community is to create better
> technology.

The challenge for the community as a whole is to accept limitations  
rather than ignore them and hope the problems that are created by  
behaving that way will magically disappear.

The IETF been talking about scalable routing = scalable multihoming  
for at least a decade and it's entirely clear that there is no pain- 
free solution that allows all the current benefits without incurring  
any of the bad side effects. Ignore this lesson at your peril.

>> IPv6 is really just repeating the same mistake with longer addresses.

> I didn't say it's a perfect solution, but we're not living in a  
> perfect
> world.

Oh, my mistake. Obviously because the world is imperfect it's ok to  
do things we know are dumb beforehand.

> If we're unable to come up with a product the market wants we
> have to accept that the market makes the most of what it's got
> regardless of what we may think about it.

Yeah, ain't capitalism grand. To quote 10cc:

To do the Wall Street Shuffle
Let your money hustle
Bet you'd sell your mother
You can buy another

> PS! I belive the probability of something entirely new replacing
> IPv<anything> is much greater than the probability of the internet
> falling apart due to its growth.

Say hi to the easter bunny if you run into it this weekend, by the  
way. Belief has no place in engineering. But it doesn't matter one  
way or the other, as I'm sure the ARIN constituents will reject it if  
it's really this great.

Delivery-date: Fri, 14 Apr 2006 10:44:47 +0000
From: "Per Heldal" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 12:42:59 +0200

On Fri, 14 Apr 2006 11:22:58 +0200, "Iljitsch van Beijnum"
<[email-masked]> said:
> On 14-apr-2006, at 10:48, Per Heldal wrote:
> 
> >> So I suggest that the IESG either:
> 
> >> 1. Tells ARIN that this policy is incompatible with work inside the
> >> IETF so it shouldn't be adopted, or
> 
> >> 2. Conclude shim6.
> 
> > That is awfully narrow-minded. The new policy indicate that V6- 
> > adoption
> > is growing,
> 
> Well, if you start at zero growing isn't that hard.
> 
> The truth of the matter is that IPv6 use is still 0% if you round to  
> a whole percentage point, and I've seen no indication that whatever  
> is needed, is needed TODAY. Shim6 is moving along well, there was no  
> reason to take action at this point in time.

Neither does anything indicate that usage (in terms of available space)
will grow to 100% anytime soon. Maybe shim6 is a viable solution at 5%
usage. Maybe it or something else yet to be invented takes over at 10%,
to the extent that the PI blocks are abandoned.

> 
> > and that it is time for operational policies to reflect
> > real-life.
> 
> If you mean that in real life, people don't care about the long term  
> they just want to be able to switch ISPs without having to renumber,  
> well, yes, this new policy reflects this. Congratulations on that.

In real life there are requirements and possible solutions. Vapor-ware
and other hallusinations don't qualify as solutions.

> 
> > Multihoming with BGP works fine today
> 
> If it works so fine, how come that only a few thousand people world  
> wide are doing it?

Because it's complex, has administrative overhead, policy restrictions
... pick whatever reason.

> 
> > How can you expect operational policies to be based on technology that
> > doesn't yet exist (feed the starving from next years crops)? From a
> > non-technical perspective, can you somehow
> > eliminate redundant connectivity and provider independence from  
> > people's
> > list of business-requirements?
> 
> You are arguing the question whether we "need" something. I'm trying  
> to argue whether we can afford to give it out. The latter trumps the  
> former.
> 
> > OTOH, this is in no way the end of shim6. The new policy is,
> > as you say, restricted to a limited number of sites.
> 
> It explicitly talks about removing some of these limitations in the  
> future. The point is that the game is now trying to get PI by lying  
> to the RIR or pushing for more relaxed rules rather than deploy shim6.

That's already an old game. A large number (maybe the majority) of
current allocations are made to entities which don't (and never will)
meet the requirements of being a transit provider.

> 
> > An alternative policy would be to make these PI
> > assignments temporary.
> 
> An alternative would be to give the prefixes out based on geography,  
> so there is at least a chance that we get to aggregate them  
> geographically in the future. But despite the fact that doing this is  
> entirely risk-free (geo PI without geo aggregation is no worse than  
> regular PI) people want proof that it works first, while at the same  
> for deploying regular PI the burden of proof is reversed so it's  
> allowed now despite very good indications (but not hard proof) that  
> it will be problematic in the future.

Geo-aggregation doesn't work in a competitive market. It would require
new routing-technology to do so, and thus fall in the same category as
shim6. 

> 
> > When alternative technology is available,
> > PI-sites could be asked to move to alternative solutions within X- 
> > years
> > or so.
> 
> Oh, and those same people that can't even be bothered to aggregate  
> two /21s into a /20 will now give up their portable address block?  
> Yeah right.

The challenge for the technical community is to create better
technology. Turn shim6 into something people want/need. Then you won't
need to force them to use it. Such a decision, made within the RIR
democracy, is easy to enforce should it be necessary. Our job as
researchers/developers/administratiors is to make sure that doesn't
become necessary.

> 
> > I do however not see how PI-assignments can be avoided
> > altogether as there is no viable technical alternative.
> 
> IPv6 is really just repeating the same mistake with longer addresses.

I didn't say it's a perfect solution, but we're not living in a perfect
world. If we're unable to come up with a product the market wants we
have to accept that the market makes the most of what it's got
regardless of what we may think about it.

//per

PS! I belive the probability of something entirely new replacing
IPv<anything> is much greater than the probability of the internet
falling apart due to its growth.
-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Fri, 14 Apr 2006 10:20:49 +0000
Date: Fri, 14 Apr 2006 12:20:06 +0200
Subject: Re: PI addressing in IPv6 advances in ARIN
From: JORDI PALET MARTINEZ <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

Hi Jim,

Not sure if I got your question correctly, but let me try to explain my
view.

I understand the position of the people that say they need PI today,
especially because not having it may be hurting the advancement of the IPv6
deployment.

However, I want to balance this with the medium-long term implications
created in the routing table and with the time needed to build and deploy a
better technical solution (or several) which is accepted by the community.

So my proposal basically is about having PI now everywhere (once ARIN adopt
it, is unfair not having it in other regions), but those PI allocations for
multihoming should be temporary and those address blocks returned to the
RIRs some time (lets say 3 years) after the new technical solution is
declared as a valid one.

At this way, on the long-run, we will not have routing table implications,
but we allow now the people that want to move ahead only if they have a
multihoming solution doing so.

This 3-years time for getting a multihoming network back to the new
technical solution (once adopted) is enough time, I think (it could be
changed to 5 years if needed, or whatever), so nobody today see the
temporarily of the proposal as a showstopper to go for it now.

Regards,
Jordi

> De: "Bound, Jim" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 14 Apr 2006 03:11:58 -0400
> Para: <[email-masked]>, <[email-masked]>
> Conversación: PI addressing in IPv6 advances in ARIN
> Asunto: RE: PI addressing in IPv6 advances in ARIN
> 
> Jordi, why this will work as is for now?
> /jim 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
>> Sent: Thursday, April 13, 2006 5:28 PM
>> To: [email-masked]
>> Subject: Re: PI addressing in IPv6 advances in ARIN
>> 
>> Hi Thomas, all,
>> 
>> During my fly-back from Montreal, I've worked in a proposal
>> and I'm talking to folks in each RIR/region, with the idea to
>> submit it to all them as a kind of (if possible), global policy.
>> 
>> The idea is based on the comments that I did at the mic
>> during the ARIN meeting.
>> 
>> I will try to get this submitted next Monday/Tuesday and get
>> ready for a formal presentation during the next RIPE meeting
>> at Istanbul (following week).
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Thomas Narten <[email-masked]>
>>> Responder a: <[email-masked]>
>>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400
>>> Para: "Gunter Van de Velde (gvandeve)" <[email-masked]>
>>> CC: "[email-masked]" <[email-masked]>
>>> Asunto: Re: PI addressing in IPv6 advances in ARIN
>>> 
>>>> What would be the prefix allocation per organization?
>>> 
>>> /48, though can be larger in some cases. Watch for the revised
>>> proposal that gets last called for details.
>>> 
>>>> (Me being in Europe and not attending ARIN sessions)
>>> 
>>> Note: none of the other RIRs have such a policy in place
>> today, though 
>>> I wouldn't be surprised if they now followup with proposals
>> of their 
>>> own (though someone has to do it).
>>> 
>>>> Has there been study on the # of organizations going for
>> this and if 
>>>> the impact will be more significant then more's law on technology
>>>> enhancement?
>>> 
>>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today,"
>>> "looking at the impact of the current IPv4 policies, the
>> number of PI 
>>> assignments is only on the 100s per year", and "we can update the
>>> policy if things get problematical".
>>> 
>>> Thomas
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be
>> for the use of the individual(s) named above. If you are not
>> the intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information,
>> including attached files, is prohibited.
>> 
>> 
>> 
>> 
>> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Fri, 14 Apr 2006 09:53:22 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 11:52:50 +0200
To: Igor Gashinsky <[email-masked]>

On 14-apr-2006, at 11:35, Igor Gashinsky wrote:

> :: But by taking this position ARIN has effectively declared that  
> the size of
> :: the routing table isn't something that the IETF should worry  
> about, so if
> :: operators run into trouble in this area they can either solve  
> this with money
> :: or filtering.

> No, what ARIN has declared is that *routing* isn't something *ARIN* is
> tasked with fixing, and its job is to hand out IP addresses (since,  
> multiple
> times before it specifically made "no claims as to "routability" of  
> those
> addresses"). Therefore, it isn't something that *ARIN* should worry  
> about.

Actually your statement and mine aren't in conflict. If ARIN believes  
that it has no role in making routing scalable (which isn't the case,  
see below) and/or takes actions that make routing non-scalable then  
apparently that's ok so the IETF doesn't have to care about this  
issue either. I'm sure the vendors that make up a large part of the  
IETF constituency don't have a problem with selling bigger and bigger  
boxes each year. Having RIR policies that make routing non-scalable  
and then have the IETF come up with mechanisms to make it scalable  
anyway is a waste of time. There are plenty of problems in routing  
that are also important that the IETF can work on and should work on,  
such as make it secure and improve convergence times.

http://www.arin.net/policy/nrpm.html

--8<--
6.3.4. Aggregation

Wherever possible, address space should be distributed in a  
hierarchical manner, according to the topology of network  
infrastructure. This is necessary to permit the aggregation of  
routing information by ISPs, and to limit the expansion of Internet  
routing tables.

This goal is particularly important in IPv6 addressing, where the  
size of the total address pool creates significant implications for  
both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address  
ranges.

--8<--

Delivery-date: Fri, 14 Apr 2006 09:35:30 +0000
Date: Fri, 14 Apr 2006 05:35:15 -0400 (EDT)
From: Igor Gashinsky <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: "Patrick W. Gilmore" <[email-masked]>, shim6-wg <[email-masked]>,  [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

:: But by taking this position ARIN has effectively declared that the size of
:: the routing table isn't something that the IETF should worry about, so if
:: operators run into trouble in this area they can either solve this with money
:: or filtering.

No, what ARIN has declared is that *routing* isn't something *ARIN* is 
tasked with fixing, and its job is to hand out IP addresses (since, multiple 
times before it specifically made "no claims as to "routability" of those 
addresses"). Therefore, it isn't something that *ARIN* should worry about.

-igor (who is very glad that this finally got pushed through)

Delivery-date: Fri, 14 Apr 2006 09:23:21 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 11:22:58 +0200
To: Per Heldal <[email-masked]>

On 14-apr-2006, at 10:48, Per Heldal wrote:

>> So I suggest that the IESG either:

>> 1. Tells ARIN that this policy is incompatible with work inside the
>> IETF so it shouldn't be adopted, or

>> 2. Conclude shim6.

> That is awfully narrow-minded. The new policy indicate that V6- 
> adoption
> is growing,

Well, if you start at zero growing isn't that hard.

The truth of the matter is that IPv6 use is still 0% if you round to  
a whole percentage point, and I've seen no indication that whatever  
is needed, is needed TODAY. Shim6 is moving along well, there was no  
reason to take action at this point in time.

> and that it is time for operational policies to reflect
> real-life.

If you mean that in real life, people don't care about the long term  
they just want to be able to switch ISPs without having to renumber,  
well, yes, this new policy reflects this. Congratulations on that.

> Multihoming with BGP works fine today

If it works so fine, how come that only a few thousand people world  
wide are doing it?

> How can you expect operational policies to be based on technology that
> doesn't yet exist (feed the starving from next years crops)? From a
> non-technical perspective, can you somehow
> eliminate redundant connectivity and provider independence from  
> people's
> list of business-requirements?

You are arguing the question whether we "need" something. I'm trying  
to argue whether we can afford to give it out. The latter trumps the  
former.

> OTOH, this is in no way the end of shim6. The new policy is,
> as you say, restricted to a limited number of sites.

It explicitly talks about removing some of these limitations in the  
future. The point is that the game is now trying to get PI by lying  
to the RIR or pushing for more relaxed rules rather than deploy shim6.

> An alternative policy would be to make these PI
> assignments temporary.

An alternative would be to give the prefixes out based on geography,  
so there is at least a chance that we get to aggregate them  
geographically in the future. But despite the fact that doing this is  
entirely risk-free (geo PI without geo aggregation is no worse than  
regular PI) people want proof that it works first, while at the same  
for deploying regular PI the burden of proof is reversed so it's  
allowed now despite very good indications (but not hard proof) that  
it will be problematic in the future.

> When alternative technology is available,
> PI-sites could be asked to move to alternative solutions within X- 
> years
> or so.

Oh, and those same people that can't even be bothered to aggregate  
two /21s into a /20 will now give up their portable address block?  
Yeah right.

> I do however not see how PI-assignments can be avoided
> altogether as there is no viable technical alternative.

IPv6 is really just repeating the same mistake with longer addresses.

Delivery-date: Fri, 14 Apr 2006 08:49:04 +0000
From: "Per Heldal" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Joe Abley" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 10:48:26 +0200

On Thu, 13 Apr 2006 23:58:27 +0200, "Iljitsch van Beijnum"
<[email-masked]> said:
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like this  
> in place shim6 will be dead in the water. Pursuing both seems a big  
> waste of time. So I suggest that the IESG either:
> 
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or
> 
> 2. Conclude shim6.

That is awfully narrow-minded. The new policy indicate that V6-adoption
is growing, and that it is time for operational policies to reflect
real-life. Multihoming with BGP works fine today, while shim6 is
vapor-ware.
We wouldn't have this discussion if shim6 had been available today with
all
the necessary supporting technologies and products for it to be widely
accepted as the superior solution .

How can you expect operational policies to be based on technology that
doesn't yet exist (feed the starving from next years crops)? From a
non-technical perspective, can you somehow
eliminate redundant connectivity and provider independence from people's
list of business-requirements? 

OTOH, this is in no way the end of shim6. The new policy is,
as you say, restricted to a limited number of sites. Besides, what about
potential advantages to the
shim approach? Its not entirely impossible that it could be developed
into something with appeal even to large networks sometime in the
future.

An alternative policy would be to make these PI
assignments temporary. When alternative technology is available,
PI-sites could be asked to move to alternative solutions within X-years
or so. I do however not see how PI-assignments can be avoided
altogether as there is no viable technical alternative.

//per
-- 
  Per Heldal
  http://heldal.eml.cc/

Delivery-date: Fri, 14 Apr 2006 07:35:13 +0000
Cc: Joe Abley <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 09:34:52 +0200
To: Jason Schiller ([email-masked]) <[email-masked]>

On 14-apr-2006, at 2:05, Jason Schiller ([email-masked]) wrote:

> I'd like to point out that if people think that PI (and placing 1 or
> more routes in the global Internet routing table) is an acceptable
> solution to multi-homing, then it is also likely that more  
> specifics of PA
> space to support multi-homing is also acceptable, and likely to  
> happen.

> This removes the fact that few people would be able to multi-home  
> in the
> traditional sense.

Actually it doesn't. It's very hard to qualify for a /22 so  
effectively this only helps Big Content. The issue of smaller ISPs or  
whole sale transit carriers that don't give out address space to  
their customers because those all have PA isn't addressed here.

But it completely changes the game: why spend time on deploying shim6  
if you can round up your IPv4 needs to get to a /22 or lobby for  
reducing the /22 requirement?

> So there are only two questions:

> 1. Is there sufficent need to continue shim6 for a no-frills easy
> multi-homing solution for consumer and small business customers  
> that can't
> or won't support BGP?

> 2. Are people concerned with the long term implacations of de- 
> aggrgegation
> for multi-homing, and if so, then should we pursue a protocol solution
> that has full support for TE in an effort to replace de- 
> aggrgegation as a
> solution and halt (or possibly reverse) the growth of the routing  
> table?

Let me add a third question: will shim6 be deployable when people can  
get PI?

Maybe shim6 can still do some good but we really need to rethink our  
goals here. I was uncomfortable with moving fast and only  
implementing bare bones mechanisms before, and even more so now. We  
should slow down and get it right the first try because if there is a  
place for shim6 in a world with IPv6 PI, that place is for a GOOD  
shim6 solution that solves the problem well, something that kinda  
works just to get something out the door isn't good enough and there  
won't be a second chance to come up with an improved version.

> BTW, I was one of six people who voted against moving forward with PI.

How many people voted in favor?

Delivery-date: Fri, 14 Apr 2006 07:25:35 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 09:25:16 +0200
To: Geoff Huston <[email-masked]>

On 14-apr-2006, at 2:31, Geoff Huston wrote:

> Personally, considering the critical consideration of scaling the  
> IPv6 technology to meet the needs of a truly massively populated  
> network in the fullness of time, I feel entirely comfortable in  
> seeing us work on this scaling issue using a number of approaches  
> at this point in time. Therefore I'm of the personal view that a  
> call to stop working on SHIM6 is somewhat ill-advised right now.

In that case the IESG should speak out against this ARIN policy. The  
ARIN decision makers should know that by doing this, they're shooting  
themselves in the foot (not to mention people outside ARIN region,  
once again I object to the fact that these policies are decided on  
regionally while the implications are global). Saying "oh well  
address policy isn't our purview" isn't good enough when it so  
clearly impacts IETF work.

The problem is that deploying shim6 won't be without challenges. If  
some people can get PI, those will have little incentive to deploy  
shim6. If they subsequently don't others that they communicate with  
don't get multihoming benefits. People who are slightly smaller will  
put effort into getting PI space too which will take away from shim6  
deployment efforts.

And the fact that they're talking about /48s shows that these people  
are fundamentally incapable of learning from the past. I direct your  
attention to this snippet of IPv4 BGP table:

*  12.236.120.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.128.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.136.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.144.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.152.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.160.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.168.0/21  4.68.0.243               0             0 3356  
7018 6478 i

Giving people adjacent blocks so that they can "grow" a single  
announcement, in very many cases they don't do this and inject each  
sub-prefix in the global routing table as a separate prefix anyway.  
So giving out /48s while reserving /44s is just plain dumb, as the  
remaining part of the /44 is never going to be allocated to anyone  
else anyway but now people are more or less forced to accept the /48s  
(believe me I'm tempted to filter them out!) even in cases where the  
prefix given out is shorter.

Delivery-date: Fri, 14 Apr 2006 07:08:09 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Fri, 14 Apr 2006 09:06:37 +0200
To: "Patrick W. Gilmore" <[email-masked]>

On 14-apr-2006, at 4:21, Patrick W. Gilmore wrote:

> Do you honestly believe the size of the routing table is the  
> biggest challenge to 'cheap' hardware pushing 100s of billions of  
> bits per second?

Does it matter if it's the biggest or second or third biggest? Fast  
memory is expensive. The amount you need scales linearly with the  
size of the routing table, and the speed you need scales linearly  
with the speed of your interface and on top of that, logarithmically  
with the size of the routing table.

But by taking this position ARIN has effectively declared that the  
size of the routing table isn't something that the IETF should worry  
about, so if operators run into trouble in this area they can either  
solve this with money or filtering.

Delivery-date: Fri, 14 Apr 2006 02:21:29 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 22:21:12 -0400
To: shim6-wg <[email-masked]>, [email-masked]

On Apr 13, 2006, at 10:12 PM, Jason Schiller ([email-masked]) wrote:

> That being the case, then in the long term do we need an  
> alturnative to
> multi-homing that does not use de-aggrgegation and that has full  
> support
> for TE?

Do you honestly believe the size of the routing table is the biggest  
challenge to 'cheap' hardware pushing 100s of billions of bits per  
second?

-- 
TTFN,
patrick

Delivery-date: Fri, 14 Apr 2006 02:20:08 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 22:19:56 -0400
To: shim6-wg <[email-masked]>, [email-masked]

On Apr 13, 2006, at 9:49 PM, Jason Schiller ([email-masked]) wrote:

> Are you saying that de-aggrgegation (individual PI or more specifics
> of one of the upstream's PA) will continue to be the only multi-homing
> solution for those who need advanced TE capabilities?

I don't want to speak for Joe, so please note this is me speaking.

"Only multi-homing solution"?  It isn't today, so why should it be  
the only solution in the future?

> Are you suggesting that the size of the IPv4 and IPv6 routing  
> system that
> results from "traditional IPv4 style" multi-homing will not be a  
> problem
> that needs to be solved by some other multi-homing solution that  
> does not
> use de-aggregation?

Yes.  The difficulties in v4 routing are not insurmountable.

I'm not sure why you are asking this, as many people have told you  
this (including me, in person) multiple times.  And explained why we  
think that way.  You can disagree, but please stop acting surprised  
when we say the same thing over again.

> Are you suggesting that hardware is or will be sufficently large to  
> be at
> least seven years ahead of the route table growth, and still remain
> affordable?

Seven years?  You've thrown that number around before, but I still do  
not see the justification for it.

Sorry if this has been said before, but I find it interesting that  
seven years ago people were saying the same thing about v4.  It's  
been seven years, and we seem to be doing OK.  In fact, the current  
routing hardware has a lot more headroom than it did back in 98/99.

I guess you could claim that OC768 interfaces costing $1M each is not  
"affordable", but I think the difficulty of switching a laser on &  
off 40 billion times per second on top of any significant routing  
decisions might have something to do with the cost.  Or are you  
saying that the cost would be an order of magnitude less if the  
router only had to deal with 30K routes instead of 180K?

There are things wrong with the global table.  Allowing people who  
need more than one transit provider to use standard IPv4 multi-homing  
techniques is not one of them.

-- 
TTFN,
patrick

Delivery-date: Fri, 14 Apr 2006 02:19:42 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 22:19:31 -0400
To: "Jason Schiller ([email-masked])" <[email-masked]>

On 13-Apr-2006, at 22:12, Jason Schiller ([email-masked]) wrote:

> That being the case, then in the long term do we need an  
> alturnative to
> multi-homing that does not use de-aggrgegation and that has full  
> support
> for TE?

I'm not yet convinced of what TE is required, and in what  
circumstances, in some future where there are alternatives to multi- 
homing with PI/covered-PA addresses.

Joe

Delivery-date: Fri, 14 Apr 2006 02:13:19 +0000
Date: Thu, 13 Apr 2006 22:12:38 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
To: Joe Abley <[email-masked]>
Cc: Jason Schiller <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

Joe,

That being the case, then in the long term do we need an alturnative to
multi-homing that does not use de-aggrgegation and that has full support
for TE? 

___Jason

=====================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Thu, 13 Apr 2006, Joe Abley wrote:

> Date: Thu, 13 Apr 2006 22:06:13 -0400
> From: Joe Abley <[email-masked]>
> To: Jason Schiller <[email-masked]>
> Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>,
>      [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
> 
> 
> On 13-Apr-2006, at 21:49, Jason Schiller ([email-masked]) wrote:
> 
> > Are you saying that de-aggrgegation (individual PI or more specifics
> > of one of the upstream's PA) will continue to be the only multi-homing
> > solution for those who need advanced TE capabilities?
> 
> No, but that's certainly one view of the future.
> 
> > Are you suggesting that the size of the IPv4 and IPv6 routing  
> > system that
> > results from "traditional IPv4 style" multi-homing will not be a  
> > problem
> > that needs to be solved by some other multi-homing solution that  
> > does not
> > use de-aggregation?
> 
> Absolutely not. I fully expect people to become more enthusiastic  
> about alternatives when things start blowing up.
> 
> > Are you suggesting that hardware is or will be sufficently large to  
> > be at
> > least seven years ahead of the route table growth, and still remain
> > affordable?
> 
> Absolutely not (especially the last one).
> 
> 
> Joe
> 

Delivery-date: Fri, 14 Apr 2006 02:06:29 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 22:06:13 -0400
To: Jason Schiller ([email-masked]) <[email-masked]>

On 13-Apr-2006, at 21:49, Jason Schiller ([email-masked]) wrote:

> Are you saying that de-aggrgegation (individual PI or more specifics
> of one of the upstream's PA) will continue to be the only multi-homing
> solution for those who need advanced TE capabilities?

No, but that's certainly one view of the future.

> Are you suggesting that the size of the IPv4 and IPv6 routing  
> system that
> results from "traditional IPv4 style" multi-homing will not be a  
> problem
> that needs to be solved by some other multi-homing solution that  
> does not
> use de-aggregation?

Absolutely not. I fully expect people to become more enthusiastic  
about alternatives when things start blowing up.

> Are you suggesting that hardware is or will be sufficently large to  
> be at
> least seven years ahead of the route table growth, and still remain
> affordable?

Absolutely not (especially the last one).

Joe

Delivery-date: Fri, 14 Apr 2006 01:51:13 +0000
Date: Thu, 13 Apr 2006 21:49:53 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
To: Joe Abley <[email-masked]>
Cc: Jason Schiller <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

Joe,

I just want to be sure I understand you.

Are you saying that de-aggrgegation (individual PI or more specifics
of one of the upstream's PA) will continue to be the only multi-homing
solution for those who need advanced TE capabilities?

Are you suggesting that the size of the IPv4 and IPv6 routing system that
results from "traditional IPv4 style" multi-homing will not be a problem
that needs to be solved by some other multi-homing solution that does not
use de-aggregation?

Are you suggesting that hardware is or will be sufficently large to be at
least seven years ahead of the route table growth, and still remain
affordable?

___Jason  

=====================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Thu, 13 Apr 2006, Joe Abley wrote:

> Date: Thu, 13 Apr 2006 20:36:00 -0400
> From: Joe Abley <[email-masked]>
> To: Jason Schiller <[email-masked]>
> Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>,
>      [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
> 
> 
> On 13-Apr-2006, at 20:05, Jason Schiller ([email-masked]) wrote:
> 
> > 2. Are people concerned with the long term implacations of de- 
> > aggrgegation
> > for multi-homing, and if so, then should we pursue a protocol solution
> > that has full support for TE in an effort to replace de- 
> > aggrgegation as a
> > solution and halt (or possibly reverse) the growth of the routing  
> > table?
> 
> The general "but we need TE" noise in response to descriptions of the  
> shim6 effort has been from ISPs and multi-homed enterprises. ISPs  
> have always been able to get PI space. Under this proposed ARIN  
> policy, multi-homed LIRs would also be able to get PI space, and as  
> you point out, the chances are that multi-homed non-LIRs would see  
> reduced resistance to advertising their PA /48s far and wide.
> 
> The small sites which cannot multi-home today in the v4 Internet  
> (e.g. residential users, small offices, mobile users) have no  
> expectation of TE, and they have no IT department who wants to stamp  
> a policy on the way they shift packets. Their upstream networks have  
> no real expectation of being able to do TE on behalf of those users  
> either, beyond whatever routine exercises they perform in response to  
> traffic which is already directed by the host (e.g. opportunistic  
> peer-to-peer traffic).
> 
> If this last category is to be the remaining constituency for a multi- 
> homing solution, and if shim6 design continues and there is  
> deployment, then I would say the one benefit of the ARIN policy from  
> the point of view of designers in this working group is that the  
> nebulous and ill-defined requirement for TE can finally be thrown  
> away :-)
> 
> 
> Joe
> 

Delivery-date: Fri, 14 Apr 2006 00:36:13 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 20:36:00 -0400
To: Jason Schiller ([email-masked]) <[email-masked]>

On 13-Apr-2006, at 20:05, Jason Schiller ([email-masked]) wrote:

> 2. Are people concerned with the long term implacations of de- 
> aggrgegation
> for multi-homing, and if so, then should we pursue a protocol solution
> that has full support for TE in an effort to replace de- 
> aggrgegation as a
> solution and halt (or possibly reverse) the growth of the routing  
> table?

The general "but we need TE" noise in response to descriptions of the  
shim6 effort has been from ISPs and multi-homed enterprises. ISPs  
have always been able to get PI space. Under this proposed ARIN  
policy, multi-homed LIRs would also be able to get PI space, and as  
you point out, the chances are that multi-homed non-LIRs would see  
reduced resistance to advertising their PA /48s far and wide.

The small sites which cannot multi-home today in the v4 Internet  
(e.g. residential users, small offices, mobile users) have no  
expectation of TE, and they have no IT department who wants to stamp  
a policy on the way they shift packets. Their upstream networks have  
no real expectation of being able to do TE on behalf of those users  
either, beyond whatever routine exercises they perform in response to  
traffic which is already directed by the host (e.g. opportunistic  
peer-to-peer traffic).

If this last category is to be the remaining constituency for a multi- 
homing solution, and if shim6 design continues and there is  
deployment, then I would say the one benefit of the ARIN policy from  
the point of view of designers in this working group is that the  
nebulous and ill-defined requirement for TE can finally be thrown  
away :-)

Joe

Delivery-date: Fri, 14 Apr 2006 00:31:51 +0000
Date: Fri, 14 Apr 2006 10:31:08 +1000
To: "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Cc: Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

SHIM6 has been chartered by the IESG to work on an identified solution 
mechanism for site multi-homing in IPv6 that does not entail placing 
further burden on the global routing system.

The solution path is one that I believe has considerable longer term 
positive implications to the IP architecture in that it is an approach that 
allows a session communication to be established in a conventional manner 
and then create a further association on an end-to-end basis that allows, 
in a relatively secure fashion, the address locators to shift within the 
session without incurring the overhead of creating additional application 
or transport level associations, without adding to the cost of the overall 
network by calling for the creation of a distribution system of yet another 
unique token .

SHIM6 will continue its chartered work, of course, and is making good 
progress with the initial specification.

The issues of scaling the routing system, and the associated consideration 
of working with the inter-domain routing system to improve its robustness 
and security also continue to be an impetus for work in this space.

Personally, considering the critical consideration of scaling the IPv6 
technology to meet the needs of a truly massively populated network in the 
fullness of time, I feel entirely comfortable in seeing us work on this 
scaling issue using a number of approaches at this point in time. Therefore 
I'm of the personal view that a call to stop working on SHIM6 is somewhat 
ill-advised right now.

kind regards,

    Geoff

Delivery-date: Fri, 14 Apr 2006 00:26:26 +0000
Date: Thu, 13 Apr 2006 20:25:37 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
To: Iljitsch van Beijnum <[email-masked]>
Cc: Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

Iljitsch,

With the exception of micro-allocations, the minimum allocation from ARIN
to an endsite in ipv4 is a /22 if you are multihomed, and a /20 if you are
not multihomed.  (Arin number resource policy manual 4.3.2)

___Jason

  (on behalf of Heather - MCI IP management)

=====================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Thu, 13 Apr 2006, Iljitsch van Beijnum wrote:

> Date: Thu, 13 Apr 2006 23:58:27 +0200
> From: Iljitsch van Beijnum <[email-masked]>
> To: Joe Abley <[email-masked]>
> Cc: shim6-wg <[email-masked]>, [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
> 
> On 13-apr-2006, at 23:38, Joe Abley wrote:
> 
> > Apologies for the circuitous, tangled path of forwarding below. I  
> > wasn't in the meeting, so I can't comment on the support that  
> > Thomas describes.
> 
> > If end-site PI assignments for anybody who wants to multi-home come  
> > to pass at ARIN, and if the other RIRs follow suit, then there  
> > would seem to be a limited opportunity for future deployment of  
> > shim6 (or, at least, substantially reduced demand for it).
> 
> > There are still the basement multi-homers who prefer not to become  
> > RIR members, of course :-)
> 
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like this  
> in place shim6 will be dead in the water. Pursuing both seems a big  
> waste of time. So I suggest that the IESG either:
> 
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or
> 
> 2. Conclude shim6.
> 
> Iljitsch
> 

Delivery-date: Fri, 14 Apr 2006 00:08:30 +0000
Date: Thu, 13 Apr 2006 20:05:36 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
To: Iljitsch van Beijnum <[email-masked]>
Cc: Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

On Thu, 13 Apr 2006, Iljitsch van Beijnum wrote:

> Although fewer people qualify under this policy
> (you need to qualify for an IPv4 block and the smallest ones that
> ARIN gives out are /20s so few people do, AFAIK) than would be able
> to use shim6, I think it's safe to say that with policies like this
> in place shim6 will be dead in the water.

Iljitsch,

I'd like to point out that if people think that PI (and placing 1 or
more routes in the global Internet routing table) is an acceptable
solution to multi-homing, then it is also likely that more specifics of PA
space to support multi-homing is also acceptable, and likely to happen.

This removes the fact that few people would be able to multi-home in the
traditional sense.

So there are only two questions:

1. Is there sufficent need to continue shim6 for a no-frills easy
multi-homing solution for consumer and small business customers that can't
or won't support BGP?

2. Are people concerned with the long term implacations of de-aggrgegation
for multi-homing, and if so, then should we pursue a protocol solution
that has full support for TE in an effort to replace de-aggrgegation as a
solution and halt (or possibly reverse) the growth of the routing table?

BTW, I was one of six people who voted against moving forward with PI.

___Jason

=====================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Thu, 13 Apr 2006, Iljitsch van Beijnum wrote:

> Date: Thu, 13 Apr 2006 23:58:27 +0200
> From: Iljitsch van Beijnum <[email-masked]>
> To: Joe Abley <[email-masked]>
> Cc: shim6-wg <[email-masked]>, [email-masked]
> Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
> 
> On 13-apr-2006, at 23:38, Joe Abley wrote:
> 
> > Apologies for the circuitous, tangled path of forwarding below. I  
> > wasn't in the meeting, so I can't comment on the support that  
> > Thomas describes.
> 
> > If end-site PI assignments for anybody who wants to multi-home come  
> > to pass at ARIN, and if the other RIRs follow suit, then there  
> > would seem to be a limited opportunity for future deployment of  
> > shim6 (or, at least, substantially reduced demand for it).
> 
> > There are still the basement multi-homers who prefer not to become  
> > RIR members, of course :-)
> 
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like this  
> in place shim6 will be dead in the water. Pursuing both seems a big  
> waste of time. So I suggest that the IESG either:
> 
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or
> 
> 2. Conclude shim6.
> 
> Iljitsch
> 

Delivery-date: Thu, 13 Apr 2006 22:28:32 +0000
Cc: Joe Abley <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
From: Marshall Eubanks <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 18:28:18 -0400
To: Iljitsch van Beijnum <[email-masked]>

On Apr 13, 2006, at 5:58 PM, Iljitsch van Beijnum wrote:

> On 13-apr-2006, at 23:38, Joe Abley wrote:
>
>> Apologies for the circuitous, tangled path of forwarding below. I  
>> wasn't in the meeting, so I can't comment on the support that  
>> Thomas describes.
>
>> If end-site PI assignments for anybody who wants to multi-home  
>> come to pass at ARIN, and if the other RIRs follow suit, then  
>> there would seem to be a limited opportunity for future deployment  
>> of shim6 (or, at least, substantially reduced demand for it).
>
>> There are still the basement multi-homers who prefer not to become  
>> RIR members, of course :-)
>
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like

While I don't think that there is a last call version yet,
2005-1 basically extends the 2002-3 micro-assignment policy to IPv6,  
and for that you have to
be multihomed and justify a /22.

Regards
Marshall

> this in place shim6 will be dead in the water. Pursuing both seems  
> a big waste of time. So I suggest that the IESG either:
>
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or
>
> 2. Conclude shim6.
>
> Iljitsch
>

Delivery-date: Thu, 13 Apr 2006 22:09:00 +0000
Cc: "Patrick W. Gilmore" <[email-masked]>
From: "Patrick W. Gilmore" <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 18:08:23 -0400
To: shim6-wg <[email-masked]>, [email-masked]

On Apr 13, 2006, at 5:58 PM, Iljitsch van Beijnum wrote:

> On 13-apr-2006, at 23:38, Joe Abley wrote:
>
>> Apologies for the circuitous, tangled path of forwarding below. I  
>> wasn't in the meeting, so I can't comment on the support that  
>> Thomas describes.
>
>> If end-site PI assignments for anybody who wants to multi-home  
>> come to pass at ARIN, and if the other RIRs follow suit, then  
>> there would seem to be a limited opportunity for future deployment  
>> of shim6 (or, at least, substantially reduced demand for it).
>
>> There are still the basement multi-homers who prefer not to become  
>> RIR members, of course :-)
>
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like this  
> in place shim6 will be dead in the water. Pursuing both seems a big  
> waste of time. So I suggest that the IESG either:
>
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or

Since when did ARIN ensure its policies were compatible with ...  
well, anything?

> 2. Conclude shim6.

Seconded. :)

-- 
TTFN,
patrick

Delivery-date: Thu, 13 Apr 2006 21:59:02 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 23:58:27 +0200
To: Joe Abley <[email-masked]>

On 13-apr-2006, at 23:38, Joe Abley wrote:

> Apologies for the circuitous, tangled path of forwarding below. I  
> wasn't in the meeting, so I can't comment on the support that  
> Thomas describes.

> If end-site PI assignments for anybody who wants to multi-home come  
> to pass at ARIN, and if the other RIRs follow suit, then there  
> would seem to be a limited opportunity for future deployment of  
> shim6 (or, at least, substantially reduced demand for it).

> There are still the basement multi-homers who prefer not to become  
> RIR members, of course :-)

Now obviously the IESG has in the past felt that multi6 and shim6  
work was valuable. Although fewer people qualify under this policy  
(you need to qualify for an IPv4 block and the smallest ones that  
ARIN gives out are /20s so few people do, AFAIK) than would be able  
to use shim6, I think it's safe to say that with policies like this  
in place shim6 will be dead in the water. Pursuing both seems a big  
waste of time. So I suggest that the IESG either:

1. Tells ARIN that this policy is incompatible with work inside the  
IETF so it shouldn't be adopted, or

2. Conclude shim6.

Iljitsch

Delivery-date: Thu, 13 Apr 2006 21:57:36 +0000
Date: Thu, 13 Apr 2006 17:57:00 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: Joe Abley <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: [[email-masked]: PI addressing in IPv6 advances in ARIN]

As one of the participants in the ARIN public policy process that led up
to this consensus, I can say I saw this coming a while ago.

Firstly, let me say that the policy we supported is not just "PI /48 for
end-sites".  It's PI /48 for end sites who qualify for an IPv4 PI /22.

Since getting involved in the IETF (partly as a result of hearing about
shim6 at NANOG/ARIN in L.A.), I've never seen shim6 (nor PI) as the
one-and-only multihoming solution for IPv6.  Instead, I see PI as
addressing the needs of large sites who prefer to multihome with BGP (with
all its TE capabilities and do-everything-in-the-network design), and
shim6 addressing the needs of host multihoming, smaller site multihoming
for folks who don't want to (or can't) run BGP, or for multihomed sites
who desire greater control on the host of the path chosen (for performance
reasons, which can be measured end-to-end).

This is why I've stressed making sure that shim6 is relatively
non-impactful to the sites who don't need it for their own multihoming, so
that they will still let their OS enable it by default, and just discard
shim6 context after it's created, letting the multihomed side keep track
of things and only keep context in failure cases.

-Scott

On 04/13/06 at 5:38pm -0400, Joe Abley <[email-masked]> wrote:

> Apologies for the circuitous, tangled path of forwarding below. I
> wasn't in the meeting, so I can't comment on the support that Thomas
> describes.
>
> If end-site PI assignments for anybody who wants to multi-home come
> to pass at ARIN, and if the other RIRs follow suit, then there would
> seem to be a limited opportunity for future deployment of shim6 (or,
> at least, substantially reduced demand for it).
>
> There are still the basement multi-homers who prefer not to become
> RIR members, of course :-)
>
> Begin forwarded message:
>
> > From: [email-masked]
> > Date: 13 April 2006 16:38:06 EDT (CA)
> > To: [email-masked]
> > Subject: [[email-masked]: PI addressing in IPv6 advances in ARIN]
> >
> > I'm sure many of you have already seen this... but finally the
> > community
> > has spoken: PI /48 for end-sites :)
> >
> > Looks like we're almost there... many thanks to everyone, Kevin and
> > Owen who
> > voiced this issue at ARIN meetings!
> >
> > james
> >
> > ----- Forwarded message from Thomas Narten <[email-masked]> -----
> >
> > To: [email-masked]
> > Subject: PI addressing in IPv6 advances in ARIN
> > Date: Thu, 13 Apr 2006 15:54:52 -0400
> > From: Thomas Narten <[email-masked]>
> >
> > FYI, at this week's ARIN meeting, there was agreement to move forward
> > with a (slightly modified) version of
> > http://www.arin.net/policy/proposals/2005_1.html, "Policy Proposal
> > 2005-1: Provider-independent IPv6 Assignments for End Sites".
> >
> > Process wise, I believe there will be an updated proposal and formal
> > last call. But there was clear support in the meeting to move forward
> > on this policy.
> >
> > This is a significant step, as no PI addresses had previously been
> > available for end sites in IPv6.
> >
> > Thomas
> >
> > ----- End forwarded message -----
> >
> > --
> > Regards,
> >
> > James Jun
> > TowardEX Technologies, Inc.
> >
> > Email: [email-masked]
> > Office: +1 617-459-4051 Ext. 179
> > Mobile: +1 978-394-2867
> > Fax: +1 432-225-3784
> >
>
>
>

Delivery-date: Thu, 13 Apr 2006 21:39:40 +0000
From: Joe Abley <[email-masked]>
Subject: Fwd: [[email-masked]: PI addressing in IPv6 advances in ARIN]
Date: Thu, 13 Apr 2006 17:38:42 -0400
To: [email-masked]

Apologies for the circuitous, tangled path of forwarding below. I  
wasn't in the meeting, so I can't comment on the support that Thomas  
describes.

If end-site PI assignments for anybody who wants to multi-home come  
to pass at ARIN, and if the other RIRs follow suit, then there would  
seem to be a limited opportunity for future deployment of shim6 (or,  
at least, substantially reduced demand for it).

There are still the basement multi-homers who prefer not to become  
RIR members, of course :-)

Begin forwarded message:

> From: [email-masked]
> Date: 13 April 2006 16:38:06 EDT (CA)
> To: [email-masked]
> Subject: [[email-masked]: PI addressing in IPv6 advances in ARIN]
>
> I'm sure many of you have already seen this... but finally the  
> community
> has spoken: PI /48 for end-sites :)
>
> Looks like we're almost there... many thanks to everyone, Kevin and  
> Owen who
> voiced this issue at ARIN meetings!
>
> james
>
> ----- Forwarded message from Thomas Narten <[email-masked]> -----
>
> To: [email-masked]
> Subject: PI addressing in IPv6 advances in ARIN
> Date: Thu, 13 Apr 2006 15:54:52 -0400
> From: Thomas Narten <[email-masked]>
>
> FYI, at this week's ARIN meeting, there was agreement to move forward
> with a (slightly modified) version of
> http://www.arin.net/policy/proposals/2005_1.html, "Policy Proposal
> 2005-1: Provider-independent IPv6 Assignments for End Sites".
>
> Process wise, I believe there will be an updated proposal and formal
> last call. But there was clear support in the meeting to move forward
> on this policy.
>
> This is a significant step, as no PI addresses had previously been
> available for end sites in IPv6.
>
> Thomas
>
> ----- End forwarded message -----
>
> --
> Regards,
>
> James Jun
> TowardEX Technologies, Inc.
>
> Email: [email-masked]
> Office: +1 617-459-4051 Ext. 179
> Mobile: +1 978-394-2867
> Fax: +1 432-225-3784
>

Delivery-date: Wed, 12 Apr 2006 15:03:14 +0000
Date: Wed, 12 Apr 2006 18:01:51 +0300
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: API for SHIM
Cc: shim6-wg <[email-masked]>

Hi Marcelo,

Thanks for your comments, please find my response inline.

On Tue, 11 Apr 2006 15:01:01 +0300
marcelo bagnulo braun <[email-masked]> wrote:

> Hi Shinta,
> 
> El 11/04/2006, a las 10:15, Shinta Sugimoto escribis:
> >>
> >> - The application should be able to tell the shim to
> >> initiate a communication with a given peer and use
> >> the shim for that.
> >> There are several cases for this:
> >>    - The connect-by-name case, where the application
> >>      indicates that it wants to initiate a communication
> >>      with a FQDN and the resolver obtain different IP
> >>      addresses for that FQDN and tries to use them to
> >>      establish the communication. Not sure if the shim
> >>      needs to be involved for this
> >
> > Yes.  I recall there have been some discussions about this topic
> > on the list.  connect_by_name() a substitute for legacy connect()
> > system call seems to be attractive for application which attempts
> > to reach its peer with multiple IP addresses.  (My understanding
> > on connect_by_name() suggested by Erik in based on his emails and
> > hope that I understand it correctly)  With regard to the question
> > if SHIM6 needs to be involved in this or not, I think there would
> > be some case where SHIM6 may have useful information that could
> > be taken into account for the peer locator selection to be done
> > by connect_by_name().  Assuming that REAP mechanism is in place
> > for verifying reachability of locator pair, that information could
> > be used to avoid unnecessary attempt of sending TCP SYNs.
> >
> 
> Right, but it is also the case that the connect by name functionality 
> can be used without the shim and it is really useful in that case too.
> I mean first of all, it is important to note that in order to make this 
> work we don't need the shim. This is so, because at the moment that 
> connect by name is performed , the ulid for that communication is being 
> determined, and it is possible to select one that is working since the 
> application has only specified the name of the target.
> So, for this communication there is no real need to have a locator that 
> differ from the ulid used for the communication, it is just enough to 
> select the ulid/locator in a smart fashion, so that  a working address 
> is selected. So no need to perform the shim translation between ulid 
> and locators in this case (Which is the main function of the shim)

Yes, I understand your statement above.  connect_by_name() is a kind of
wrapper to connect() system call in a sense that it only requires app
to provide hostname rather than the IP address.  Then the library would
take care of name resolution and session establishment for each
resolved address.  As you pointed out, SHIM6 is not required to make
this work.  What I want to point out is that connect_by_name() might
be able to coordinate with SHIM6 REAP mechanism.

> 
> IMHO this is very good because the connect by shim funtiobality can be 
> used even when the peer does no supports the shim and it would allow to 
> establish new communications in the case of a failure in the multihomed 
> site.

Agree.

> 
> Of course, if we don't use the shim we will need to use other than shim 
> messages to figure out if the address pair is working. however, 
> considering that this is connect by name, probing with TCP syns seems 
> the natural options and i don't see any drawback, do you?

No.  I am not saying that probing by TCP SYNs should be replaced by
SHIM6 probe message.  I am saying that unnecessary attempt of sending
TCP SYNs to the un-working locator pairs *can* be avoided if the
SHIM6 REAP state indicates that the locator pair is supposedly
unreachable.

> (note that it is not trivial to use REAP messages, since the probe 
> messages need to be associated to an established shim context, which is 
> not the case here, since we are trying to establish a context. Probably 
> I1 packet would be a better option)

You are right that SHIM6 probe message is associated with a context.

> >>    - The connect to an ULID case. In this case the
> >>      application decides to establish a communication
> >>      with a given ULID and the shim may be required
> >>      if the ULID is unreachable/unroutable. The shim
> >>      will attempt to establish a context using the
> >>      ULID selected by the application and using
> >>      alternative locators. The question is how does
> >>      the shim retrieves the alternative locators?
> >>      The options for this may be to cache information
> >>      obtained by the DNS (i.e. when the query for a
> >>      FQDN returns multiple addresses, these are passed
> >>      to the shim as a hint about alternative locators)
> >>      The other option would be to use the reverse DNS,
> >>      as suggested in draft-nordmark-shim6-esd-00.
> >
> > I see.  In the first alternative solution you mention above,
> > I feel that we need to look into the relation between resolver,
> > connect() system call, and SHIM and how see if the interaction
> > could be done in architecturally clean way.
> >
> 
> note that in this case, we need the shim, because as opposed to the 
> previous case, the ulid for the communication has been selected by the 
> ulp and cannot be changed

Right.  SHIM6 context establishment should be kicked if the
selected ULID of the peer is not reachable/routable as you
mentioned above.

> >>    - In addition, the application may want to inform
> >>      about locators that are not working, or in
> >>      particular that the ULID is not reachable. This
> >>      may be useful in the case that the application
> >>      is triggering the shim context establishment
> >>      because of a failure in an ongoing communication.
> >
> > Ok.  Trigger may be needed for initial contact (the previous
> > issue) too.
> 
> right.
> 
> you mean that the application can inform that the initial contact has 
> failed and that it wants to establish a communication with the peer, so 
> that the shim6 context needs to be established, right? this would be 
> like the trigger for the previous point right?

Yes.

> >> - The application should be able to inform the shim
> >>    about the timeout values for detecting a failure,
> >>    for sending keepalives, for starting the exploration
> >>    procedure. In particular, the application should be
> >>    able to suppress the keepalives
> >
> > Ok.  TCP keepalive and reachability/failure detection to be
> > performed by REAP are semantically identical, which implies
> > that there could be a chance to better coordinate.
> >
> 
> well, i was more thinking about data traffic and tcp acks, which allow 
> the app to tell that a communication is progressing properly...

I see.  Different aspect.

> >> - The application should be able to inform the shim
> >>    if hot stand-by is desired, so that alternative paths
> >>    are being probed when the current locator pair is
> >>    working.
> >
> > Ok.  This is also mentioned in the appendix of shim6-proto-04
> > document, I guess.
> >
> >> - The application should be able to tell how aggressive
> >>    the alternative path exploration procedure is desired
> >>    i.e. the number of alternative path that are probed
> >>    in parallel
> >
> > This seems to be related issue to the one before (hot stand-by).
> > I assume that the case would apply for an application which is
> > more sensitive to the e2e delay, for example.
> >
> 
> 
> well, there seem to be somehow different issues, i guess
> 
> The previous point is about probing alternative locator pair while the 
> current locator is still working, in order to have an alternative path 
> that we know that is working
> (Actually this information could be obtained if there are other 
> contexts with overlapping locator pairs, and that are using another 
> locator pair as current locator pair)

Ok.

> This point is about how many locator pairs a node tries in parallel, 
> after a failure.
> 
> both of them are related to how fast an alternative path is discovered, 
> only that the first option implies traffic even if no outage occurs.

Ok, understood.

> >> - The application should be able to request not using
> >>    the shim for this communication
> >
> > Yes.
> >
> >> - Forking related options. In particular, the
> >>    application should be able to request the creation
> >>    of a Forked Instance for a context, and should be
> >>    able to set the preferences for that forked instance,
> >>    the same as a regular context.
> >
> > This is one of the main issues of API.
> > I understand that forked context can be specifically used by
> > each application (process).  IMO, the question is how could
> > application have a reference to specific forked context.
> > Forked context could be identified by the FII, of course.
> > But it does not seem to be suitable/easy for application to use
> > it as a referral of locator.  So far, I think it would make
> > sense to allow application to specify ULID as well as
> > preferred locator (if any) to send/receive packet to/from
> > given socket.
> >
> 
> but this could identify more than one forked contexts, right?
> i mean, there is nothing precluding that two forked contexts of the 
> same original context use the same locator pair... in this case, 
> locator pair and ulid pair does not identifies a single forked 
> context... not sure if this is problem though....

Yes, but what can SHIM6 API provide application then ?
Do you think that app should specify FII via socket API ?

> >> - The application should be able to inform that an outage
> >>    has occurred. Also it should be able to inform that the
> >>    performance of the current locator pair is not
> >>    satisfactory any more and that the shim should launch
> >>    exploration and an alternative locator pair that works
> >>    better (for some definition of better that may be
> >>    included in the request.
> >
> > Right.  This is another need for trigger.
> >
> >> - The application should be able to select a locator pair.
> >>    A particular case for this, is that application should
> >>    be able to tell the shim that it prefers using the ULID
> >>    pair as locator pair as long as they are working.
> >
> > Ok.  I suppose that this is mainly to avoid invoking unnecessary
> > re-homing event.
> 
> i see it as mean to avoid the payload header in data traffic once that 
> the original path is restored..

> >> - The application should be capable of obtaining the
> >>    locator sets, local and remote, available for a shim
> >>    context. In addition, the application should be able to
> >>    obtain the preferences for that locators as well as other
> >>    information, such whether the locator is reachable or not.
> >
> > I am not sure how much would the system-wide preference make sense.
> > (see below)
> >
> >> - The application should be able to set the preferences for
> >>    the locators, local and remote one and also to the
> >>    preferences of the local locators that will be passed to
> >>    the peer.
> >
> > This makes more sense to me (than the one before) as each
> > application would probably have own preference for locators.
> > The SHIM6 context is per ULID pair, which means that context
> > can be allocated per application, but not necessarily per
> > application.  It is basically system-wide.  So in this sense,
> > there is slightly a gap between application's need and what
> > SHIM6 provides.
> >
> 
> well, you have the forked context for that.
> As i see it, there will be some system wide preferences that are 
> applied to all context by default. However, a given application can 
> override this preferences using the API especially for the forked 
> contexts... not sure if an application should be allowed to override 
> the preferences of a context that it has not forked, because in this 
> case we may end up with different apps trying t change the preferences 
> and having contradictory requests...

Ok, application should refer to specific forked context (how it can/should
be is still open issue though) which also contains preference information
of the locator.

> >> - Interaction between RFC3484 and the shim. In this case,
> >>    the information available in the shim could be used to
> >>    influence RFC3484 selection procedure, so that
> >>    unreachable locators are avoided.
> >
> > I see.  And I tend to think that application may also want to
> > distinguish locator with its type.  In case of running SHIM6
> > over MIPv6, application may want to distinguish HoA and CoA
> > for achieving better performance (maybe by taking advantage of
> > SHIM6 based RO mode), for instance.
> 
> but this is already built in the rfc3484 right? i mean, rfc3484 already 
> preffers HoAs over Coas... besides, the basic SHIM over MIP scenario 
> does not assumes that CoAs are exposed to the shim, i guess

Yes, RFC3484 mentions about HoA and CoA.  It recommends to have higher
preference on HoA over CoA.  In plain Mobile IPv6 environment,
behavior following the recommendation would probably fulfill users
desire.  But in some advanced scenarios, app may prefer CoA for
better performance (SHIM6 based RO).  RFC3484 does not help to do this.

> >> Others??
> >
> > In addition, we would probably need a mechanism for providing
> > application ancillary data that are related to SHIM6 behavior.
> > For instance, application may want to know which locator was
> > *actually* used to receive/send given IP datagram.
> >
> 
> you mean about packets sent in the past?

No.  I am talking about the ancillary data which (extended)
Socket API may provide from SHIM6 perspective.  What I have in mind
is that application may want to know src/dst locators
which were actually used to deliver the packet to the host.
Well, it may sound contradictory to the basic concept of SHIM6
which is to make locator information transparent to the ULP.
But some application may still want to know (for some reason)
what is the decision made by the underlying SHIM6 layer in
locator selection.  In the past discussions on SHIM6 & TE, it
was suggested to allow locator rewriting at the site exit router.
So, in SHIM6 a host may receive an IP packet on the locator
which is not the preferred one.  But I don't have the answer for
a question why would the application need such info ...

My statement above only considers inbound packet processing.

> I am not sure that the shim needs to keep the historical data of 
> locators used for any reason.... why would you require that for?

see above.

Regards,
Shinta

Delivery-date: Tue, 11 Apr 2006 20:23:09 +0000
Date: Wed, 12 Apr 2006 06:22:08 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt
Cc: kurt Erik Lindqvist <[email-masked]>

Hi,

This is a reminder for any others who intend to post comments on this 
document, now would be a Good Time to do so!

     Thanks,

      Geoff & Kurtis

Folks,

         This note starts the WG Last Call for comments on
         draft-ietf-shim6-proto-04.txt, "Level 3 multi-homing shim
         protocol".

         It can be found at:
         ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-proto-04.txt

         The document is intended to be submitted by the Working Group
         to the IESG for publication as a Proposed Standard.

         Please review the document carefully, and send your feedback to the
         SHIM6 list.  Please also indicate in your response whether or not
         you believe that this document is ready to go to the IESG.

         This Last Call will end on Friday 14 Apr 2006 at 0800 AEST
         (UTC+10).

         Thanks,

               Geoff & Kurtis

----------------------------------------------------------

Additional comments to this Last Call:

o The three week period for the WG Last Call is to allow some leeway for
   post-IETF recovery!

o We also note that we have an outstanding topic of compatibility with
   Mobile IPv6 and SHIM6 as discussed in the Working Group meeting this
   week. This last call has been generated on the basis of verbal advice
   provided by the document's editors that this matter has been discussed
   with Mobile IPv6 folk and that there are no serious issues of
   incompatibility anticipated. I expect a note to this effect from Marcelo
   Bagnulo summarizing the outcomes of this discussion to be posted to the
   SHIM6 WG during this Last Call period.

o We have consulted with the technical advisors to this Working Group and
   they have indicated that are happy for us to proceed with this last call at
   this time.

Delivery-date: Tue, 11 Apr 2006 12:02:22 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: API for SHIM
Date: Tue, 11 Apr 2006 15:01:01 +0300
To: Shinta Sugimoto <[email-masked]>

Hi Shinta,

El 11/04/2006, a las 10:15, Shinta Sugimoto escribió:
>>
>> - The application should be able to tell the shim to
>> initiate a communication with a given peer and use
>> the shim for that.
>> There are several cases for this:
>>    - The connect-by-name case, where the application
>>      indicates that it wants to initiate a communication
>>      with a FQDN and the resolver obtain different IP
>>      addresses for that FQDN and tries to use them to
>>      establish the communication. Not sure if the shim
>>      needs to be involved for this
>
> Yes.  I recall there have been some discussions about this topic
> on the list.  connect_by_name() a substitute for legacy connect()
> system call seems to be attractive for application which attempts
> to reach its peer with multiple IP addresses.  (My understanding
> on connect_by_name() suggested by Erik in based on his emails and
> hope that I understand it correctly)  With regard to the question
> if SHIM6 needs to be involved in this or not, I think there would
> be some case where SHIM6 may have useful information that could
> be taken into account for the peer locator selection to be done
> by connect_by_name().  Assuming that REAP mechanism is in place
> for verifying reachability of locator pair, that information could
> be used to avoid unnecessary attempt of sending TCP SYNs.
>

Right, but it is also the case that the connect by name functionality 
can be used without the shim and it is really useful in that case too.
I mean first of all, it is important to note that in order to make this 
work we don't need the shim. This is so, because at the moment that 
connect by name is performed , the ulid for that communication is being 
determined, and it is possible to select one that is working since the 
application has only specified the name of the target.
So, for this communication there is no real need to have a locator that 
differ from the ulid used for the communication, it is just enough to 
select the ulid/locator in a smart fashion, so that  a working address 
is selected. So no need to perform the shim translation between ulid 
and locators in this case (Which is the main function of the shim)

IMHO this is very good because the connect by shim funtiobality can be 
used even when the peer does no supports the shim and it would allow to 
establish new communications in the case of a failure in the multihomed 
site.

Of course, if we don't use the shim we will need to use other than shim 
messages to figure out if the address pair is working. however, 
considering that this is connect by name, probing with TCP syns seems 
the natural options and i don't see any drawback, do you?

(note that it is not trivial to use REAP messages, since the probe 
messages need to be associated to an established shim context, which is 
not the case here, since we are trying to establish a context. Probably 
I1 packet would be a better option)

>>    - The connect to an ULID case. In this case the
>>      application decides to establish a communication
>>      with a given ULID and the shim may be required
>>      if the ULID is unreachable/unroutable. The shim
>>      will attempt to establish a context using the
>>      ULID selected by the application and using
>>      alternative locators. The question is how does
>>      the shim retrieves the alternative locators?
>>      The options for this may be to cache information
>>      obtained by the DNS (i.e. when the query for a
>>      FQDN returns multiple addresses, these are passed
>>      to the shim as a hint about alternative locators)
>>      The other option would be to use the reverse DNS,
>>      as suggested in draft-nordmark-shim6-esd-00.
>
> I see.  In the first alternative solution you mention above,
> I feel that we need to look into the relation between resolver,
> connect() system call, and SHIM and how see if the interaction
> could be done in architecturally clean way.
>

note that in this case, we need the shim, because as opposed to the 
previous case, the ulid for the communication has been selected by the 
ulp and cannot be changed

>>    - In addition, the application may want to inform
>>      about locators that are not working, or in
>>      particular that the ULID is not reachable. This
>>      may be useful in the case that the application
>>      is triggering the shim context establishment
>>      because of a failure in an ongoing communication.
>
> Ok.  Trigger may be needed for initial contact (the previous
> issue) too.

right.

you mean that the application can inform that the initial contact has 
failed and that it wants to establish a communication with the peer, so 
that the shim6 context needs to be established, right? this would be 
like the trigger for the previous point right?

>
>> - The application should be able to inform the shim
>>    about the timeout values for detecting a failure,
>>    for sending keepalives, for starting the exploration
>>    procedure. In particular, the application should be
>>    able to suppress the keepalives
>
> Ok.  TCP keepalive and reachability/failure detection to be
> performed by REAP are semantically identical, which implies
> that there could be a chance to better coordinate.
>

well, i was more thinking about data traffic and tcp acks, which allow 
the app to tell that a communication is progressing properly...

>> - The application should be able to inform the shim
>>    if hot stand-by is desired, so that alternative paths
>>    are being probed when the current locator pair is
>>    working.
>
> Ok.  This is also mentioned in the appendix of shim6-proto-04
> document, I guess.
>
>> - The application should be able to tell how aggressive
>>    the alternative path exploration procedure is desired
>>    i.e. the number of alternative path that are probed
>>    in parallel
>
> This seems to be related issue to the one before (hot stand-by).
> I assume that the case would apply for an application which is
> more sensitive to the e2e delay, for example.
>

well, there seem to be somehow different issues, i guess

The previous point is about probing alternative locator pair while the 
current locator is still working, in order to have an alternative path 
that we know that is working
(Actually this information could be obtained if there are other 
contexts with overlapping locator pairs, and that are using another 
locator pair as current locator pair)

This point is about how many locator pairs a node tries in parallel, 
after a failure.

both of them are related to how fast an alternative path is discovered, 
only that the first option implies traffic even if no outage occurs.

>>
>> - The application should be able to request not using
>>    the shim for this communication
>
> Yes.
>
>> - Forking related options. In particular, the
>>    application should be able to request the creation
>>    of a Forked Instance for a context, and should be
>>    able to set the preferences for that forked instance,
>>    the same as a regular context.
>
> This is one of the main issues of API.
> I understand that forked context can be specifically used by
> each application (process).  IMO, the question is how could
> application have a reference to specific forked context.
> Forked context could be identified by the FII, of course.
> But it does not seem to be suitable/easy for application to use
> it as a referral of locator.  So far, I think it would make
> sense to allow application to specify ULID as well as
> preferred locator (if any) to send/receive packet to/from
> given socket.
>

but this could identify more than one forked contexts, right?
i mean, there is nothing precluding that two forked contexts of the 
same original context use the same locator pair... in this case, 
locator pair and ulid pair does not identifies a single forked 
context... not sure if this is problem though....

>> - The application should be able to inform that an outage
>>    has occurred. Also it should be able to inform that the
>>    performance of the current locator pair is not
>>    satisfactory any more and that the shim should launch
>>    exploration and an alternative locator pair that works
>>    better (for some definition of better that may be
>>    included in the request.
>
> Right.  This is another need for trigger.
>
>> - The application should be able to select a locator pair.
>>    A particular case for this, is that application should
>>    be able to tell the shim that it prefers using the ULID
>>    pair as locator pair as long as they are working.
>
> Ok.  I suppose that this is mainly to avoid invoking unnecessary
> re-homing event.

i see it as mean to avoid the payload header in data traffic once that 
the original path is restored..

>
>> - The application should be capable of obtaining the
>>    locator sets, local and remote, available for a shim
>>    context. In addition, the application should be able to
>>    obtain the preferences for that locators as well as other
>>    information, such whether the locator is reachable or not.
>
> I am not sure how much would the system-wide preference make sense.
> (see below)
>
>> - The application should be able to set the preferences for
>>    the locators, local and remote one and also to the
>>    preferences of the local locators that will be passed to
>>    the peer.
>
> This makes more sense to me (than the one before) as each
> application would probably have own preference for locators.
> The SHIM6 context is per ULID pair, which means that context
> can be allocated per application, but not necessarily per
> application.  It is basically system-wide.  So in this sense,
> there is slightly a gap between application's need and what
> SHIM6 provides.
>

well, you have the forked context for that.
As i see it, there will be some system wide preferences that are 
applied to all context by default. However, a given application can 
override this preferences using the API especially for the forked 
contexts... not sure if an application should be allowed to override 
the preferences of a context that it has not forked, because in this 
case we may end up with different apps trying t change the preferences 
and having contradictory requests...

>> - Interaction between RFC3484 and the shim. In this case,
>>    the information available in the shim could be used to
>>    influence RFC3484 selection procedure, so that
>>    unreachable locators are avoided.
>
> I see.  And I tend to think that application may also want to
> distinguish locator with its type.  In case of running SHIM6
> over MIPv6, application may want to distinguish HoA and CoA
> for achieving better performance (maybe by taking advantage of
> SHIM6 based RO mode), for instance.

but this is already built in the rfc3484 right? i mean, rfc3484 already 
preffers HoAs over Coas... besides, the basic SHIM over MIP scenario 
does not assumes that CoAs are exposed to the shim, i guess

>
>> Others??
>
> In addition, we would probably need a mechanism for providing
> application ancillary data that are related to SHIM6 behavior.
> For instance, application may want to know which locator was
> *actually* used to receive/send given IP datagram.
>

you mean about packets sent in the past?

I am not sure that the shim needs to keep the historical data of 
locators used for any reason.... why would you require that for?

regards, marcelo

>
> Regards,
> Shinta
>

Delivery-date: Tue, 11 Apr 2006 07:17:02 +0000
Date: Tue, 11 Apr 2006 10:15:35 +0300
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: API for SHIM
Cc: shim6-wg <[email-masked]>

Hi Marcelo and all,

Excuse me for responding lately to the original email, but let me provide
some comments/views on this topic.  I started paying closer look at
API stuff.

On Wed, 8 Mar 2006 16:16:10 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> Hi,
> 
> I guess that one of the issues that are open for discussion is the API 
> for shim. In order to continue the discussion on this, I have tried to 
> identify the potentials options for an extended API for SHIM that have 
> been brought up in the list
> 
> Here it is an initial version of the list from the stuff that i recall 
> that have been discussed over the years here.
> 
> - The application should be able to tell the shim to
> initiate a communication with a given peer and use
> the shim for that.
> There are several cases for this:
>    - The connect-by-name case, where the application
>      indicates that it wants to initiate a communication
>      with a FQDN and the resolver obtain different IP
>      addresses for that FQDN and tries to use them to
>      establish the communication. Not sure if the shim
>      needs to be involved for this

Yes.  I recall there have been some discussions about this topic
on the list.  connect_by_name() a substitute for legacy connect()
system call seems to be attractive for application which attempts
to reach its peer with multiple IP addresses.  (My understanding
on connect_by_name() suggested by Erik in based on his emails and
hope that I understand it correctly)  With regard to the question
if SHIM6 needs to be involved in this or not, I think there would
be some case where SHIM6 may have useful information that could
be taken into account for the peer locator selection to be done
by connect_by_name().  Assuming that REAP mechanism is in place
for verifying reachability of locator pair, that information could
be used to avoid unnecessary attempt of sending TCP SYNs.

>    - The connect to an ULID case. In this case the
>      application decides to establish a communication
>      with a given ULID and the shim may be required
>      if the ULID is unreachable/unroutable. The shim
>      will attempt to establish a context using the
>      ULID selected by the application and using
>      alternative locators. The question is how does
>      the shim retrieves the alternative locators?
>      The options for this may be to cache information
>      obtained by the DNS (i.e. when the query for a
>      FQDN returns multiple addresses, these are passed
>      to the shim as a hint about alternative locators)
>      The other option would be to use the reverse DNS,
>      as suggested in draft-nordmark-shim6-esd-00.

I see.  In the first alternative solution you mention above,
I feel that we need to look into the relation between resolver,
connect() system call, and SHIM and how see if the interaction
could be done in architecturally clean way.

>    - In addition, the application may want to inform
>      about locators that are not working, or in
>      particular that the ULID is not reachable. This
>      may be useful in the case that the application
>      is triggering the shim context establishment
>      because of a failure in an ongoing communication.

Ok.  Trigger may be needed for initial contact (the previous
issue) too.

> - The application should be able to inform the shim
>    about the timeout values for detecting a failure,
>    for sending keepalives, for starting the exploration
>    procedure. In particular, the application should be
>    able to suppress the keepalives

Ok.  TCP keepalive and reachability/failure detection to be
performed by REAP are semantically identical, which implies
that there could be a chance to better coordinate.

> - The application should be able to inform the shim
>    if hot stand-by is desired, so that alternative paths
>    are being probed when the current locator pair is
>    working.

Ok.  This is also mentioned in the appendix of shim6-proto-04
document, I guess.

> - The application should be able to tell how aggressive
>    the alternative path exploration procedure is desired
>    i.e. the number of alternative path that are probed
>    in parallel

This seems to be related issue to the one before (hot stand-by).
I assume that the case would apply for an application which is
more sensitive to the e2e delay, for example.

> 
> - The application should be able to request not using
>    the shim for this communication

Yes.

> - Forking related options. In particular, the
>    application should be able to request the creation
>    of a Forked Instance for a context, and should be
>    able to set the preferences for that forked instance,
>    the same as a regular context.

This is one of the main issues of API.
I understand that forked context can be specifically used by
each application (process).  IMO, the question is how could
application have a reference to specific forked context.
Forked context could be identified by the FII, of course.
But it does not seem to be suitable/easy for application to use
it as a referral of locator.  So far, I think it would make
sense to allow application to specify ULID as well as
preferred locator (if any) to send/receive packet to/from
given socket.

> - The application should be able to inform that an outage
>    has occurred. Also it should be able to inform that the
>    performance of the current locator pair is not
>    satisfactory any more and that the shim should launch
>    exploration and an alternative locator pair that works
>    better (for some definition of better that may be
>    included in the request.

Right.  This is another need for trigger.

> - The application should be able to select a locator pair.
>    A particular case for this, is that application should
>    be able to tell the shim that it prefers using the ULID
>    pair as locator pair as long as they are working.

Ok.  I suppose that this is mainly to avoid invoking unnecessary
re-homing event.

> - The application should be capable of obtaining the
>    locator sets, local and remote, available for a shim
>    context. In addition, the application should be able to
>    obtain the preferences for that locators as well as other
>    information, such whether the locator is reachable or not.

I am not sure how much would the system-wide preference make sense.
(see below)

> - The application should be able to set the preferences for
>    the locators, local and remote one and also to the
>    preferences of the local locators that will be passed to
>    the peer.

This makes more sense to me (than the one before) as each
application would probably have own preference for locators.
The SHIM6 context is per ULID pair, which means that context
can be allocated per application, but not necessarily per
application.  It is basically system-wide.  So in this sense,
there is slightly a gap between application's need and what
SHIM6 provides.

> - Interaction between RFC3484 and the shim. In this case,
>    the information available in the shim could be used to
>    influence RFC3484 selection procedure, so that
>    unreachable locators are avoided.

I see.  And I tend to think that application may also want to
distinguish locator with its type.  In case of running SHIM6
over MIPv6, application may want to distinguish HoA and CoA
for achieving better performance (maybe by taking advantage of
SHIM6 based RO mode), for instance.

> Others??

In addition, we would probably need a mechanism for providing
application ancillary data that are related to SHIM6 behavior.
For instance, application may want to know which locator was
*actually* used to receive/send given IP datagram.

Regards,
Shinta

Delivery-date: Thu, 06 Apr 2006 13:34:03 +0000
Cc: [email-masked], Thomas Narten <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE 
Date: Thu, 6 Apr 2006 16:33:51 +0300
To: Pekka Savola <[email-masked]>

El 06/04/2006, a las 16:28, Pekka Savola escribió:

> On Thu, 6 Apr 2006, Thomas Narten wrote:
> ...
>>> So this only works if there are no DNS caches in the middle, AFAICS.
>>
>> I'm not following something here. Could you elaborate? Caching doesn't
>> mess things up in the DNS, unless one is using kludgery that is known
>> to be inconsistent with the basic DNS architecture.
>
> Exactly .. the inbound TE part would be exactly such kludgery.. which 
> is why it shouldn't be used :-)
>

unless remote resolvers explicitly query for the SRV records, and they 
use that information to order the list of addresses returned to the 
app, in which case this works and does not require upgrading the app to 
query for SRV records. In this case, there is no kludgery AFAICT and it 
seems to work fine and be easier to deploy. imho this may be useful if 
we go to the path of using the DNS to express preferences about 
locators for incoming 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: Thu, 06 Apr 2006 13:28:33 +0000
Date: Thu, 6 Apr 2006 16:28:14 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Thomas Narten <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: transparent addrsel policy adjustment for outbound TE 

On Thu, 6 Apr 2006, Thomas Narten wrote:
...
>> So this only works if there are no DNS caches in the middle, AFAICS.
>
> I'm not following something here. Could you elaborate? Caching doesn't
> mess things up in the DNS, unless one is using kludgery that is known
> to be inconsistent with the basic DNS architecture.

Exactly .. the inbound TE part would be exactly such kludgery.. which 
is why it shouldn't be used :-)

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

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Apr 2006 13:02:51 +0000
Message-Id: <[email-masked]>
To: Pekka Savola <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: transparent addrsel policy adjustment for outbound TE 
Date: Thu, 06 Apr 2006 09:01:52 -0400
From: Thomas Narten <[email-masked]>

Pekka Savola <[email-masked]> writes:

> >> This doesn't really help with inbound TE though.  (One could add similar 
> >> function the site's authoritative DNS server, and unmodified resolvers 
> >> might comply with that policy, but caching DNS servers would mess this up.)
> >> 
> >
> > why?
> > i agree that the expressed policy has to be quite stable, i mean, the cache 
> > will introduce certain inertia, and changing the preferences may take some 
> > time, but at least you can express some preferences about which addresses the 
> > site preffers for incoming communications...

> The problem is that DNS caches in the middle will cache both IP_1 and 
> IP_2, but lose the "preference" which is conveyed by the weighted 
> address ordering, because from the DNS cache perspective IP_1 and IP_2 
> are equivalent.

> So this only works if there are no DNS caches in the middle, AFAICS.

I'm not following something here. Could you elaborate? Caching doesn't
mess things up in the DNS, unless one is using kludgery that is known
to be inconsistent with the basic DNS architecture.

Thomas

Delivery-date: Wed, 05 Apr 2006 13:23:38 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-ietf-shim6-app-refer-00.txt
Date: Wed, 5 Apr 2006 16:23:28 +0300

Hi all,

I wanted to ask what happen with draft-ietf-shim6-app-refer-00.txt

I mean i can't find it anymore in the wg page listed as a wg draft

Did we drop this work from the wg?

I think this is a really valuable document and has provided much 
guidance for the design of the shim solution. imho it would be useful 
to publish it as an informational RFC

Thanks, marcelo

Delivery-date: Wed, 05 Apr 2006 13:21:16 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Wed, 5 Apr 2006 16:20:44 +0300
To: Scott Leibrand <[email-masked]>

El 05/04/2006, a las 15:44, Scott Leibrand escribió:

> On 04/05/06 at 10:05am +0300, marcelo bagnulo braun  
> <[email-masked]> wrote:
>
>> El 04/04/2006, a las 18:44, Scott Leibrand escribió:
>>
>>>> locator selecting proxy == rewriting source address by exit routers
>>>
>>> That's not how I see it.  Since the source locator doesn't influence
>>> the path a packet takes, source locator rewriting matters most for
>>> getting through source-address filters, and secondarily for
>>> influencing the end hosts to use a different destination locators  
>>> than
>>> they might otherwise.
>>
>> not really, but i see your point. I think that there is a middle  
>> ground
>> here, let me expand on this.
>>
>> If you don't have source address rewriting, and we assume that ingress
>> filters are in place (which seems the by default assumption) then the
>> source address selection actually determines the exit path form the
>> multihomed site.
>
> Not in today's networks.  Currently routers route on destination  
> address,
> not source address, so the destination address selection determines  
> which
> route is used to route the packets, which in turn determines which  
> source
> address you have to use if you want your packets to get out.
>

agree, but in case of a site with multiple prefixes delegated by  
different providers and where the providers perform ingress filtering,  
you need something like this...
It is not that i like it, but i haven't heard any better option yet...  
any ideas?

>> I mean, if a multihomed site wants to avoid that the ISP filters drop
>> packets, then it must make sure that the packet is forwarded through  
>> the
>> ISP that corresponds to the prefix included in the source address. So
>> actually when the host selects the source address, it is de facto
>> selecting the site exit ISP. (for more about this see
>> http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- 
>> filtering-00.txt)
>
> I've seen assertions that sites implementing shim6 will want to choose
> their egress path based on source address.  But in today's deployed
> production networks, the only way to do that is by manually configuring
> something like PBR or VRF, which is roughly equivalent to static source
> routing.  There's no such thing yet AFAIK as a dynamic source routing
> protocol.

i know that this is not the way it is done today and i know that there  
is no dynamic support for this (at least the last time i checked)
still some form of source address based routing as the ones described  
in the draft seems to be the available options to deal with this.
please note that the shim6 protocol assumes that changing the source  
address somehow affects the exit path. I mean the shim6 host only can  
change the addresses, so the assumption is that a change in the address  
affects the path. If you consider the case of a host that has two  
addresses and it is communicating with a peer that has only one  
address, then all he can do is to change the source address, and this  
should imply some change in the path....

>
>> The nice thing of this approach is that it doesn't need to store per
>> shim context state. It just needs to be aware of the prefixes  
>> available
>> in the site.
>>
>> If we move to a full locator selection proxy as you mention, we  
>> require
>> per shim6 context state in the proxy, agree?
>
> Correct.
>
>>>> well at least one issue that needs to be addressed in this model is
>>>> about address delegation.
>>>> i mean, the shim6 security is based on using HBAs and/or CGAs.
>>>> This means that at least the address that is going to be used in the
>>>> host must be a CGA or an HBA set.
>>>
>>> Couldn't the security simply be moved from the end host to the shim6
>>> proxy?  You're still assuming end-to-end shim6 security, but if the
>>> end host doesn't speak shim6 in the first place, the logical place  
>>> for
>>> shim6 HBA/CGA security is not on the end host, but on the proxy where
>>> shim6 is actually being performed.
>>
>> Yes, but that host needs to have at least one address, right?
>
> Yes, although it would be equivalent to a non-routable identifier, and
> *not* part of the shim6 locator set.  (Strictly speaking, the ULID is
> still routable, but we wouldn't be using it for routing.)
>

but they would be placed in the DNS right?
i mean these are the IP level identifiers of the hosts, the IP  
identity, right?

>> And this address will be ULID used in the end to end shim6 context,
>> right?
>
> Correct.
>
>> So, if this is so, then this address needs to be whether a HBA or a
>> CGA, hence my previous comment applies.
>>
>> That is, in the case of the HBA, it would be possible for the proxy to
>> generate the HBA set and use something like DHCP to delegate the
>> address to the host
>
> Yuck.  That eliminates a lot of possibilities.

not sure what you had in mind, but maybe there is some way to make it  
work :-)

>
>> Now, the host is not aware that there is anything special in that
>> address(es) but the proxy knows that they form an HBA set, so he can
>> use them in the  shim6 protocol interchangeably as locators.
>>
>> If the CGA approach is used, it is a bit more complex, since the ULID
>> must be a CGA.
>
> Why must a ULID not used as a locator be a CGA or HBA?

Yes, what is more, a locator may not be included in the HBA set and may  
not be a CGA, as long it is signed by the CGA.
OTOH, the ULID must always be a HBA or a CGA. This is basically because  
the ULID is what you want to protect the most, since it is the identity  
of the host. We need to prove identifier ownership in order to prevent  
redirection attacks (see the threat analysis RFC4218)

>   If the end hosts
> don't support shim6, CGA, or HBA to begin with, why can't the proxy  
> just
> use HBA/CGA to generate a self-consistent locator set, and leave the  
> ULID
> (end host IP) out of that set?

no, the ULID must be part of the HBA set or the CGA

but, again, the host may acquire the address from the proxy, using  
DHCP, i guess

>
>>> Yes, I would agree.  And the more we talk about it, the more I think
>>> that a full shim6 proxy has to maintain the full locator set locally,
>>> and just treat the host's IP as a non-routable ULID, not as an
>>> additional locator.
>>
>> ok, but in this case you would need a non routable prefix to assign  
>> non
>> routable ULIDs, ULAs?
>
> Not really.  What I'm thinking is that for initial pre-shim  
> communication,
> hosts would use the ULIDs directly.  Then, when shim6 negotiation is
> successfully performed, the locator set exchanged *does not* contain  
> the
> ULID as a locator.  The ULID is still routable in the general sense,  
> but
> since it's not a locator under the proxy's control, it is treated as  
> just
> an identifier and not a locator.

so the ulid is a routable/valid locator, but is simply not included in  
the locator set of the shim6 context?

what is the goal of this configuration?

>
>> and you would be losing some referral callback support in this case.
>
> I'm not familiar with was referral callback is in this context...
>

see http://www.watersprings.org/pub/id/draft-ietf-shim6-app-refer-00.txt

regards, marcelo

> -Scott
>

Delivery-date: Wed, 05 Apr 2006 12:44:51 +0000
Date: Wed, 5 Apr 2006 08:44:40 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: Shim6 proxies

On 04/05/06 at 10:05am +0300, marcelo bagnulo braun <[email-masked]> wrote:

> El 04/04/2006, a las 18:44, Scott Leibrand escribió:
>
> >> locator selecting proxy == rewriting source address by exit routers
> >
> > That's not how I see it.  Since the source locator doesn't influence
> > the path a packet takes, source locator rewriting matters most for
> > getting through source-address filters, and secondarily for
> > influencing the end hosts to use a different destination locators than
> > they might otherwise.
>
> not really, but i see your point. I think that there is a middle ground
> here, let me expand on this.
>
> If you don't have source address rewriting, and we assume that ingress
> filters are in place (which seems the by default assumption) then the
> source address selection actually determines the exit path form the
> multihomed site.

Not in today's networks.  Currently routers route on destination address,
not source address, so the destination address selection determines which
route is used to route the packets, which in turn determines which source
address you have to use if you want your packets to get out.

> I mean, if a multihomed site wants to avoid that the ISP filters drop
> packets, then it must make sure that the packet is forwarded through the
> ISP that corresponds to the prefix included in the source address. So
> actually when the host selects the source address, it is de facto
> selecting the site exit ISP. (for more about this see
> http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress-filtering-00.txt)

I've seen assertions that sites implementing shim6 will want to choose
their egress path based on source address.  But in today's deployed
production networks, the only way to do that is by manually configuring
something like PBR or VRF, which is roughly equivalent to static source
routing.  There's no such thing yet AFAIK as a dynamic source routing
protocol.

> The nice thing of this approach is that it doesn't need to store per
> shim context state. It just needs to be aware of the prefixes available
> in the site.
>
> If we move to a full locator selection proxy as you mention, we require
> per shim6 context state in the proxy, agree?

Correct.

> >> well at least one issue that needs to be addressed in this model is
> >> about address delegation.
> >> i mean, the shim6 security is based on using HBAs and/or CGAs.
> >> This means that at least the address that is going to be used in the
> >> host must be a CGA or an HBA set.
> >
> > Couldn't the security simply be moved from the end host to the shim6
> > proxy?  You're still assuming end-to-end shim6 security, but if the
> > end host doesn't speak shim6 in the first place, the logical place for
> > shim6 HBA/CGA security is not on the end host, but on the proxy where
> > shim6 is actually being performed.
>
> Yes, but that host needs to have at least one address, right?

Yes, although it would be equivalent to a non-routable identifier, and
*not* part of the shim6 locator set.  (Strictly speaking, the ULID is
still routable, but we wouldn't be using it for routing.)

> And this address will be ULID used in the end to end shim6 context,
> right?

Correct.

> So, if this is so, then this address needs to be whether a HBA or a
> CGA, hence my previous comment applies.
>
> That is, in the case of the HBA, it would be possible for the proxy to
> generate the HBA set and use something like DHCP to delegate the
> address to the host

Yuck.  That eliminates a lot of possibilities.

> Now, the host is not aware that there is anything special in that
> address(es) but the proxy knows that they form an HBA set, so he can
> use them in the  shim6 protocol interchangeably as locators.
>
> If the CGA approach is used, it is a bit more complex, since the ULID
> must be a CGA.

Why must a ULID not used as a locator be a CGA or HBA?  If the end hosts
don't support shim6, CGA, or HBA to begin with, why can't the proxy just
use HBA/CGA to generate a self-consistent locator set, and leave the ULID
(end host IP) out of that set?

> > Yes, I would agree.  And the more we talk about it, the more I think
> > that a full shim6 proxy has to maintain the full locator set locally,
> > and just treat the host's IP as a non-routable ULID, not as an
> > additional locator.
>
> ok, but in this case you would need a non routable prefix to assign non
> routable ULIDs, ULAs?

Not really.  What I'm thinking is that for initial pre-shim communication,
hosts would use the ULIDs directly.  Then, when shim6 negotiation is
successfully performed, the locator set exchanged *does not* contain the
ULID as a locator.  The ULID is still routable in the general sense, but
since it's not a locator under the proxy's control, it is treated as just
an identifier and not a locator.

> and you would be losing some referral callback support in this case.

I'm not familiar with was referral callback is in this context...

-Scott

Delivery-date: Wed, 05 Apr 2006 12:42:40 +0000
Date: Wed, 05 Apr 2006 14:42:17 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Scott Leibrand <[email-masked]>, [email-masked]
Subject: Re: Shim6 proxies

Excuse front posting but these comments are quite general.

What Scott is describing is essentially full offload of the
shim and the bottom part of the stack. We'd actually end
up with two IP stacks - one in the host which just sends
packets to the offload device, and a second one in the
offload device which has a shim on top of it. I'd want to
see a complete architecture for that including a demonstration
that the security architecture of shim6 isn't damaged,
and analysis of the trust model and threat model
between the host and the offload device. But if it can be
done, it has a very nice property - it actually offers
a practical way to implement something that works much like
8+8. The offload device will be state-heavy though; it will
need to carry state per session for every host it's supporting.

Whether that offload device is in the same rack as a few tens of
servers that it supports, or is a separate proxy for a few hundred
hosts, or is built into a site border router, seems secondary
in the architecture.

      Brian

marcelo bagnulo braun wrote:
> 
> El 04/04/2006, a las 18:44, Scott Leibrand escribió:
> 
> ...
> 
>>> locator selecting proxy = rewriting source address by exit routers
>>
>>
>> That's not how I see it.  Since the source locator doesn't influence  the
>> path a packet takes, source locator rewriting matters most for getting
>> through source-address filters, and secondarily for influencing the end
>> hosts to use a different destination locators than they might  otherwise.
>>
> 
> not really, but i see your point. I think that there is a middle ground  
> here, let me expand on this.
> 
> If you don't have source address rewriting, and we assume that ingress  
> filters are in place (which seems the by defualt assumption) then the  
> source address selection actually determines the exit path form the  
> multihomed site. I mean, if a multihomed site wants to avoid that the  
> ISP filters drop packets, then it must make sure that the packet is  
> forwarded through the ISP that corresponds to the prefix included in  
> the source address. So actually when the host selects the source  
> address, it is de facto selecting the site exit ISP. (for more about  
> this see  
> http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- 
> filtering-00.txt)
> 
> So, if you allow site exit router to rewrite the source address prefix,  
> you are actually restoring to the intra site routing system the  
> capability of actually selecting the exit path of a packet _given a  
> destiantion_
> 
> So, here i agree with your point, the other part that needs to be taken  
> into account is destiantion locator selection.
> 
> So, esd draft off loads part of the locator/path selection i.e. the  
> source address prefix while the other part is still in the host itself.
> 
> The nice thing of this approach is that it doesn't need to store per  
> shim context state. It just needs to be aware of the prefixes available  
> in the site.
> 
> If we move to a foll locator selection proxy as you mention, we require  
> per shim6 context state in the proxy, agree?
> 
> 
>> To me, a full locator selecting proxy would do the entire shim6
>> negotiation, keep the locator sets internally, choose *both* the source
>> and destination locators to use, and supply preferences to the far  
>> side to
>> influence which ones it uses.  IOW, it would perform *all* the  functions
>> of the shim.  This is substantially different from just rewriting  source
>> address,
> 
> 
> agree that is different
> 
>>  which doesn't give you any additional TE control unless it
>> influences the far side's destination locator selection.
>>
> 
> but it does provides additional TE control by allowing the selection of  
> the site exit path for a given destiantion, agree?
> 
>>> the benefit of doing it this way as opposed to provide hints to the
>>> hosts about which source address to use, is that the management of the
>>> policy is in the scope of the routing system/admin, rather than in the
>>> hosts themselves, which seems to be an important management issue for
>>> some sites.
>>
>>
>> In order for the routing system/admin to have full TE control, he would
>> have to be in control of the choice of destination locator.  By the  time
>> he gets the packets, it's too late for that, and all he can do is  
>> rewrite
>> the source locator
> 
> 
> so far agree
> 
>> and hope that his rewriting sufficiently influences the
>> end hosts so that they switch to using the locators preferred by the
>> router.
>>
> 
> but the effects of rewriting the source address are more important that  
> just that, since it allows the routing system to actually select the  
> exit path for that destiantion
> 
>>>> If you're going to do a full proxy, you have to go all the way IMO.
>>>> That means that for whatever locators the end hosts use, whether they
>>>> have multiple locators are not, have to be assumed to be fixed for  the
>>>> session, just like ULIDs.  The shim6 proxy would then intercept all
>>>> shim6 control traffic to that IP, and perform the shim functions on
>>>> behalf of the host. It would have a bunch of its own locators, which
>>>> would make up the locator set.  It could also include the ULID as one
>>>> of those locators, and intercept traffic to that IP with shim6
>>>> headers, or I suppose it could treat the host's IP as a non-routable
>>>> identifier for shim6 purposes and just use its own locators in the
>>>> locator set.  Either way, the proxy would process all shim6-tagged
>>>> traffic for the host, de-shim it as normal, and then pass the traffic
>>>> along to the host's IP instead of passing it up to the ULP.
>>>>
>>>> Does that sound reasonable?  What problems do you see with such a
>>>> setup?
>>>
>>>
>>> well at least one issue that needs to be addressed in this model is
>>> about address delegation.
>>> i mean, the shim6 security is based on using HBAs and/or CGAs.
>>> This means that at least the address that is going to be used in the
>>> host must be a CGA or an HBA set.
>>
>>
>> Couldn't the security simply be moved from the end host to the shim6
>> proxy?  You're still assuming end-to-end shim6 security, but if the end
>> host doesn't speak shim6 in the first place, the logical place for  shim6
>> HBA/CGA security is not on the end host, but on the proxy where shim6  is
>> actually being performed.
> 
> 
> Yes, but that host needs to have at least one address, right?
> 
> And this address will be ULID used in the end to end shim6 context,  right?
> 
> So, if this is so, then this address needs to be whether a HBA or a  
> CGA, hence my previous comment applies.
> 
> That is, in the case of the HBA, it would be possible for the proxy to  
> generate the HBA set and use something like dhcp to delegate the  
> address to the host
> 
> Now, the host is not aware that there is anything special in that  
> address(es) but the proxy knows that they form an HBA set, so he can  
> use them in the  shim6 protocol interchangeably as locators.
> 
> If the CGA approach is used, it is a bit more complex, since the ULID  
> must be a CGA. Again the proxy can generate it, and delegate it to the  
> host using dhcp. Now, since the proxy is aware of the private key of  
> the CGA it can perform the shim6 protocol. But in this case, we still  
> need to figure out what would happen if the host needs to use the CGa  
> for some other protocol (e.g. SeND)
> 
> 
> 
>>
>>> In the HBA case, the problem could be addressed if the host obtains  the
>>> addresses from the proxy (e.g. using dhcp) and it configures the whole
>>> HBA set. The point here is that the host cannot have any other
>>> addresses, because if he use the other addresses, then the proxy won't
>>> be able to run the shim6 protocol with those
>>>
>>> If we are using CGAs, then the proxy needs to be aware of the private
>>> key associated with the CGA (and the CGA parameter data structure) or
>>> we could define some form of delegating rights from the host to the
>>> proxy.
>>
>>
>> I'm working under the assumption that the end host *doesn't* do HBA or
>> CGA, but instead just does IPv6 with a single address (for each
>> connection).
> 
> 
> yes but this address will be the ULID used in the shim6 contexts hence  
> it msut be part of the HBA set or a CGA, see above
> 
>>  In this case the shim6 proxy would contain the entire
>> HBA/CGA set, and would perform all the security functions on behalf 
>> of  the
>> host.  Since the host doesn't even know that this shim6 thing exists,  he
>> doesn't have to do anything special security-wise.
>>
>>> In any case, we need to figure out how this interacts with other host
>>> based protocols that also use CGAs, like how do you run this with SeND
>>
>>
>> I can't say I understand CGAs well enough to comment on the  implications
>> of this...
>>
>>>> The most obvious one is that if you use the host's actual IP as one
>>>> of the locators, you risk missing some shim6-tagged traffic if there
>>>> is more than one route to the host.
>>>
>>>
>>> yes, but this is in the nature of the proxy approach, i mean, clearly
>>> the shim would become a single point of failure in this case, but i  see
>>> this as inherent of a solution of this type, and it still provides  some
>>> additional fault tolerance for these hosts that don't support the  shim6
>>> protocol
>>
>>
>> Yes, I would agree.  And the more we talk about it, the more I think  
>> that
>> a full shim6 proxy has to maintain the full locator set locally, and  
>> just
>> treat the hosts's IP as a non-routable ULID, not as an additional  
>> locator.
>>
> 
> ok, but in this case you would need a non routable prefix to assign non  
> routable ULIDs, ULAs? and you would be loosing some referal callback  
> support in this case.
> 
> Regards, marcelo
> 
> 
>>>>   That could be alleviated by only using local locators in the  locator
>>>> set, and treating the host's IP as an unroutable locator in shim6.
>>>> If you did that, I guess there's the same problem I complained about
>>>> in Erik's esd draft, which is that the host at the other end is  forced
>>>> to shim6-tag all packets and maintain shim6 state for the duration of
>>>> the session.
>>
>>
>> -Scott
>>
> 
> 
> 
> 

Delivery-date: Wed, 05 Apr 2006 12:34:07 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE
Date: Wed, 5 Apr 2006 15:33:58 +0300
To: Pekka Savola <[email-masked]>

El 05/04/2006, a las 15:27, Pekka Savola escribió:

> Hi,
>
> I think the summary is:
>
> This mechanism could be useful in moving SRV lookup implementation 
> from the applications to the stub resolver.
>
> In addition even without SRV lookups, it could be used for outbound TE 
> policy distribution mechanism, though the benefits compared to (for 
> example) DHCPv6-based policy distribution are questionable as you'd 
> need to distribute the stub resolver policies using some other 
> mechanism (e.g., DHCPv6 ;-).
>

yes

and as an inbound policy mechanisms if the remote resolvers support this

the next question for the remote hosts imho is how to combine remote 
and local policy information

regards, marcelo

> On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
>>>> i agree that the expressed policy has to be quite stable, i mean, 
>>>> the cache will introduce certain inertia, and changing the 
>>>> preferences may take some time, but at least you can express some 
>>>> preferences about which addresses the site preffers for incoming 
>>>> communications...
>>> The problem is that DNS caches in the middle will cache both IP_1 
>>> and IP_2, but lose the "preference" which is conveyed by the 
>>> weighted address ordering, because from the DNS cache perspective 
>>> IP_1 and IP_2 are equivalent.
>>
>> but my assumption is that the remote resolver will also query for the 
>> SRV record as local hosts do, so the SRV information will be 
>> retrieved also (perhaps from the caches, but this is no problem if it 
>> is not very dynamic)
>>
>> wouldn't this work?
>
> Indeed, it would work fine if SRV lookups would be done by remote 
> resolvers.
>
> I was thinking one step ahead, the scenarios where the remote 
> resolvers don't have SRV lookup support.  Authoritative DNS servers at 
> a local site could do the policy adjustment by weighing the responses, 
> but it wouldn't really work due to caching (and to smaller degree, 
> resolver's reordering of addresses).
>
> -- 
> 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, 05 Apr 2006 12:28:11 +0000
Date: Wed, 5 Apr 2006 15:27:52 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: transparent addrsel policy adjustment for outbound TE

Hi,

I think the summary is:

This mechanism could be useful in moving SRV lookup implementation 
from the applications to the stub resolver.

In addition even without SRV lookups, it could be used for outbound TE 
policy distribution mechanism, though the benefits compared to (for 
example) DHCPv6-based policy distribution are questionable as you'd 
need to distribute the stub resolver policies using some other 
mechanism (e.g., DHCPv6 ;-).

On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
>>> i agree that the expressed policy has to be quite stable, i mean, the 
>>> cache will introduce certain inertia, and changing the preferences may 
>>> take some time, but at least you can express some preferences about which 
>>> addresses the site preffers for incoming communications...
>> 
>> The problem is that DNS caches in the middle will cache both IP_1 and IP_2, 
>> but lose the "preference" which is conveyed by the weighted address 
>> ordering, because from the DNS cache perspective IP_1 and IP_2 are 
>> equivalent.
>
> but my assumption is that the remote resolver will also query for the SRV 
> record as local hosts do, so the SRV information will be retrieved also 
> (perhaps from the caches, but this is no problem if it is not very dynamic)
>
> wouldn't this work?

Indeed, it would work fine if SRV lookups would be done by remote 
resolvers.

I was thinking one step ahead, the scenarios where the remote 
resolvers don't have SRV lookup support.  Authoritative DNS servers at 
a local site could do the policy adjustment by weighing the responses, 
but it wouldn't really work due to caching (and to smaller degree, 
resolver's reordering of addresses).

-- 
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, 05 Apr 2006 12:12:43 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE
Date: Wed, 5 Apr 2006 15:12:27 +0300
To: Pekka Savola <[email-masked]>

El 05/04/2006, a las 14:54, Pekka Savola escribió:

> On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
>> I mean, since the SRV record has this special name associated, it may 
>> not trivial for the resolver to figure out which SRV record to query 
>> if the application wants to initiate a communication with 
>> machine1.foo.com
>>
>> so perhaps it makes sense to go all the way and use new RR
>
> Could be though, it could probably be trivial to define a something 
> special like _shim6._ip.FQDN
>

makes sense

>>> This would not have any negative impact on the application as all 
>>> the addresses would still be there but the ordering would just be 
>>> modified based on preferences, though running transparent SRV 
>>> lookups could incur delays etc. if it's not done in parallel.
>>>
>>> This could be very effective means for outbound TE decisions without 
>>> a need to touch applications at all.
>>
>> well, actually i see it exactly the opposite :-)
>> this is really useful for inbound TE
>>
>> I mean, outbound TE is the easy part, since the multihomed site is in 
>> control of the packets and it can route them however it wants to. So, 
>> outbound TE can be done by affecting routing or by configuring the 
>> source address selection policy table and so on.
>
> Simple routing changes don't help if ingress filtering is in place, 
> because the sources select the addresses and have to be routed in a 
> very restricted manner.

right, i was thinking in two scenarios:
- in one case, we have routing system based policy, in which case we 
need router rewriting
- in the other case, we have policy distributed to the hosts, and it 
influences source address selection

>   A part of this is an alternative means for "policy distribution" for 
> hosts, I guess.
>

ok, i see, you are considering this as somehow centralized policy 
server where the local hosts can get policy information from. Something 
like NAROS, but using the DNS instead of a new protocol.

Yes this could be an option, but defining a dhcp opcion for 
distributing rfc3484 policy table could be also. I guess this depends 
on how much information the policy implies. I mean, in one approach, 
the host stores all the policy information in the rfc3484 policy table 
(which may work if this is not much information and it has a good 
performance because it does not require a query for each new 
destiantion). the other approach, the host only stores the information 
about the destiantions that it is communicating with, which requires 
less storage capability but imposes a query each time a new destiantion 
is contacted.

>>> This doesn't really help with inbound TE though.  (One could add 
>>> similar function the site's authoritative DNS server, and unmodified 
>>> resolvers might comply with that policy, but caching DNS servers 
>>> would mess this up.)
>>
>> why?
>> i agree that the expressed policy has to be quite stable, i mean, the 
>> cache will introduce certain inertia, and changing the preferences 
>> may take some time, but at least you can express some preferences 
>> about which addresses the site preffers for incoming 
>> communications...
>
> The problem is that DNS caches in the middle will cache both IP_1 and 
> IP_2, but lose the "preference" which is conveyed by the weighted 
> address ordering, because from the DNS cache perspective IP_1 and IP_2 
> are equivalent.
>

but my assumption is that the remote resolver will also query for the 
SRV record as local hosts do, so the SRV information will be retrieved 
also (perhaps from the caches, but this is no problem if it is not very 
dynamic)

wouldn't this work?

regards, marcelo

> So this only works if there are no DNS caches in the middle, AFAICS.
>
> -- 
> 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, 05 Apr 2006 11:55:34 +0000
Date: Wed, 5 Apr 2006 14:54:45 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: transparent addrsel policy adjustment for outbound TE

On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
> I mean, since the SRV record has this special name associated, it may not 
> trivial for the resolver to figure out which SRV record to query if the 
> application wants to initiate a communication with machine1.foo.com
>
> so perhaps it makes sense to go all the way and use new RR

Could be though, it could probably be trivial to define a something 
special like _shim6._ip.FQDN

>> This would not have any negative impact on the application as all the 
>> addresses would still be there but the ordering would just be modified 
>> based on preferences, though running transparent SRV lookups could incur 
>> delays etc. if it's not done in parallel.
>>
>> This could be very effective means for outbound TE decisions without a need 
>> to touch applications at all.
>
> well, actually i see it exactly the opposite :-)
> this is really useful for inbound TE
>
> I mean, outbound TE is the easy part, since the multihomed site is 
> in control of the packets and it can route them however it wants to. 
> So, outbound TE can be done by affecting routing or by configuring 
> the source address selection policy table and so on.

Simple routing changes don't help if ingress filtering is in place, 
because the sources select the addresses and have to be routed in a 
very restricted manner.  A part of this is an alternative means for 
"policy distribution" for hosts, I guess.

>> This doesn't really help with inbound TE though.  (One could add similar 
>> function the site's authoritative DNS server, and unmodified resolvers 
>> might comply with that policy, but caching DNS servers would mess this up.)
>> 
>
> why?
> i agree that the expressed policy has to be quite stable, i mean, the cache 
> will introduce certain inertia, and changing the preferences may take some 
> time, but at least you can express some preferences about which addresses the 
> site preffers for incoming communications...

The problem is that DNS caches in the middle will cache both IP_1 and 
IP_2, but lose the "preference" which is conveyed by the weighted 
address ordering, because from the DNS cache perspective IP_1 and IP_2 
are equivalent.

So this only works if there are no DNS caches in the middle, AFAICS.

-- 
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, 05 Apr 2006 09:43:24 +0000
Cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]
Date: Wed, 5 Apr 2006 12:42:50 +0300
To: Scott Leibrand <[email-masked]>

El 04/04/2006, a las 19:02, Scott Leibrand escribió:

> On 04/04/06 at 2:16pm +0300, marcelo bagnulo braun 
> <[email-masked]> wrote:
>
>>> I disagree with this.  If a rewriting-capable host, which may or may
>>> not have a rewriting router on the path, started up communication
>>> observing these SHOULDs, then the host it's talking to, which may be 
>>> a
>>> very busy non-multihomed (or PI-multihomed) server, would have to 
>>> keep
>>> full shim6 context and would be unable to discard it during
>>> communication due to the presence of shim6 extension headers on every
>>> packet.  This would be true even if no source-rewriting routers were
>>> deployed, and no one gained any benefit from the capability.
>>>
>>> IMO a better approach would be to continue using deferred context
>>> establishment (except in the identifier/locator split case, of
>>> course), and initially only put the Sent Locator Pair option packets
>>> that already have shim6 headers (shim6 control packets and any 
>>> packets
>>> sent with non-ULID locators).  Then, *if* source locator rewriting is
>>> done by a router on *those* packets, you can start putting shim6
>>> extension headers on all ULP payload packets.
>>
>> I guess that what you want is first to discover if there is router
>> rewriting in the path and if this is so, then enable this capability 
>> for
>> the particular shim6 context.
>
> Yes, I agree.  We just have to figure out how to do that.  :)
>
>> The problem that i see with this is that i don't think it is trivial 
>> to
>> detect if a rewriting router is in the path. In particular, i don't
>> think that the context establishment exchange is enough to detect such
>> presence, especially because it may well happen that during the 
>> context
>> establishment exchange, the source address match with what the router
>> would have rewritten, and even if there is a rewriting router in the
>> path, the source address is unchanged.
>
> That is true.  BUT, if the router doesn't need to rewrite the source
> address, is there a need for shim6-tagging every packet?  IOW, if the
> hosts are already doing what the router wants them to, it can just sit
> back and let them continue.
>

ok, i may agree with this, but you still need to avoid deferred context 
establishment in this case. I mean, i agree with the point that if the 
shim6 context estalishment exchenge does not needs rewriting, then it 
is likely that the data packets won't need it neither (depending on how 
dynamic the policy is anyway)
So i guess it may be reasonable to send the I1,R1,I2,R2 and see if 
there is a rewriting router on path.
If it is, then the host needs to include the payload header in all data 
packets to allow rewriting
If not, it may skip that and the peer can tear down the context

but still we need to avoid deferred context estbalishment in this case, 
in order to figure out early in the communication if we need rewriting 
or not

> Now I suppose the router might change its TE preferences in 
> mid-session,
> and want to start rewriting locators.  But in that case, I think it 
> could
> just do so on shim6 packets, leaving the non-shim6-tagged packets 
> alone as
> it would have to do for non-shim6-capable hosts.  That way all new 
> flows
> could be rewritten and redirected, without impacting hosts that aren't
> shim6-capable, or hosts that don't want to keep all their shim6 state.
> (In fact, there's no difference between the two as far as a router is
> concerned.)

yes, but depending how dynamic the policy is and how much control the 
admin of the site wants, this may be acceptable or not

>
>> I guess it hard to have both aggressive garbage collection and source
>> address rewriting and i guess each site will prefer one capability
>> over the other. So i guess that the best we could do is to provide
>> tools so that each site can benefit from the capability that it
>> prefers the most.
>
> I agree.  And in order to do so, we have to ensure that the decisions 
> of
> one site (say a multihomed small site) to *support* source address
> rewriting doesn't automatically impact all the shim6-capable hosts it
> talks to.

well, shim context establishment requires acceptance from both peers, 
so both parties must agree. However, once that the context is 
established, it seems rasonable to expect that both parties will keep 
the context if this is needed (at least by one of the parties)

not sure what is the behaviour that you would expect

regards, marcelo

>   Rather, we need to make sure that the only time we require both
> sides to keep full shim6 context is when a router in the path has 
> already
> performed source locator rewriting.
>

> -Scott
>

Delivery-date: Wed, 05 Apr 2006 08:24:30 +0000
Cc: shim6-wg <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Possible modification to the shim6 base spec (was:Re: Shim6 failure recovery after garbage collection)
Date: Wed, 5 Apr 2006 11:23:49 +0300
To: Scott Leibrand <[email-masked]>

El 04/04/2006, a las 18:46, Scott Leibrand escribió:

> On 04/04/06 at 1:17pm +0300, marcelo bagnulo braun 
> <[email-masked]> wrote:
>
>>
>> El 30/03/2006, a las 21:42, Scott Leibrand escribió:
>>>> Do you see any problems with this behaviour?
>>>
>>> Yes, I do.  Say you have a one-way data transfer, from a busy server
>>> that aggressively garbage-collects shim6 context to a multihomed 
>>> shim6
>>> client. The client at some point establishes shim6 context, which the
>>> server promptly discards.  The client requests a bunch of data, which
>>> the server sends.  The last data packet from the server clears the
>>> keepalive timer, but it is restarted again when the client ACKs the
>>> last packet.  Since the server has no more data to send, the 
>>> keepalive
>>> timer expires.  This prompts the client to send a shim6 keepalive,
>>> which in turn generates an R1bis message and re-establishes the
>>> context.  IMO this unnecessary context re-establishment could pose a
>>> problem for sites who can't afford any additional state on their
>>> servers, especially if it happens repeatedly and prevents the server
>>> from garbage-collecting the state a second time.
>>
>> yes, i remember Jari commenting something about this issue, that it
>> seems that a couple of additional packets were needed to finish the
>> process... And yes, this seems to have bad impact on this case where
>> server's aggressively garbage collect
>>
>> So i agree this is an issue...
>>
>> I wonder if it would be ok not to send R1bis as reply to keepalive
>> message, (but send it as a reply to probe messages)
>>
>> In this case, the reception of a keepalive wouldn't trigger a R1bis,
>> which would deal with this case.
>
> But wouldn't the lack of a keepalive cause the keepalive timer on the
> sending side to time out?
>

ok let me recap the scenario here.

We have a client C and a server S.

The establish a communication and the establish a shim6 context

S rapidly discards the state while C keeps it

Suppose that this was a TCP connection so that the packet exchenge is 
such that there is no need for additional keepalive messages during the 
communication.

The problem that you pointed out was about what happens when the 
communications ends, that it would require some keepalive exchange.

Let's first consider the case where the last TCP ack was sent by the 
Server.
In this case, S doesn't do anything because it doesn't have any 
context, but C, upon the reception of this packet, starts the timer to 
send a keepalive. since C has no more data traffic to send, then it 
generates a keepalive. When S receives the keepalive, It would simply 
drop it (if we asume the modification proposed above), and the 
communication ends gracefully without need of re establishing the lost 
context.

However, if we consider the other scenario, where it is the client who 
sends the last TCP, the situation is different.
C sends the last TCP ACK and  starts the timer, waiting for incoming 
traffic.
S receives the TCP ACK but doesn't send a keepalive, because it doesn't 
have any shim6 state.
C doesn't receives any traffic so it starts the full exploration 
procedure, which would result in restoring the lost context.

So, not replying a R1bis to keepalive messages only solves one half of 
the problem, when the last packet was generated by the server.

I don't know how to deal with the other case though... any ideas?

>> In the case that the lost context needs to be recovered, the impact is
>> that this is delayed until the peer decides to perform an
>> exploration...
>
> And wouldn't the expiration of the keepalive timer trigger an 
> exploration?
>
>> Do you think this would be a good approach?
>>
>>
>>
>>>> OTOH, it may make sense to explicitly state in the draft what a
>>>> payload packet is...
>>>
>>> Yeah, I think we need to at least talk about it there, as it seemed
>>> rather ambiguous to me.
>>
>> In the failure detection draft you mean, right? (not in the shim6 
>> proto
>> spec)
>
> Wherever it is we define behavior based on payload packets, we should
> define such packets.  I don't recall which draft that's in...
>

well, been rereading the faildet draft and it states that:

    This document defines the protocol mechanisms only for the third
    task.  We employ a technique called Forced Bidirectional Detection
    (FBD).  Reachability for the currently used address pair in a shim
    context is determined by making sure that whenever there is data
    traffic in one direction, there is also traffic in the other
    direction.  This can be data traffic as well, but also transport
    layer acknowledgments or a REAP reachability keepalive if there is no
    other traffic.  This way, it is no longer possible to have traffic in
    only one direction, so whenever there is data traffic going out, but
    there are no return packets, there must be a failure, so the full
    path exploration mechanism is started.

wouldn't this be enough?

regards, marcelo

> -Scott
>

Delivery-date: Wed, 05 Apr 2006 07:05:55 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Wed, 5 Apr 2006 10:05:38 +0300
To: Scott Leibrand <[email-masked]>

El 04/04/2006, a las 18:44, Scott Leibrand escribió:

...
>> locator selecting proxy == rewriting source address by exit routers
>
> That's not how I see it.  Since the source locator doesn't influence  
> the
> path a packet takes, source locator rewriting matters most for getting
> through source-address filters, and secondarily for influencing the end
> hosts to use a different destination locators than they might  
> otherwise.
>

not really, but i see your point. I think that there is a middle ground  
here, let me expand on this.

If you don't have source address rewriting, and we assume that ingress  
filters are in place (which seems the by defualt assumption) then the  
source address selection actually determines the exit path form the  
multihomed site. I mean, if a multihomed site wants to avoid that the  
ISP filters drop packets, then it must make sure that the packet is  
forwarded through the ISP that corresponds to the prefix included in  
the source address. So actually when the host selects the source  
address, it is de facto selecting the site exit ISP. (for more about  
this see  
http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- 
filtering-00.txt)

So, if you allow site exit router to rewrite the source address prefix,  
you are actually restoring to the intra site routing system the  
capability of actually selecting the exit path of a packet _given a  
destiantion_

So, here i agree with your point, the other part that needs to be taken  
into account is destiantion locator selection.

So, esd draft off loads part of the locator/path selection i.e. the  
source address prefix while the other part is still in the host itself.

The nice thing of this approach is that it doesn't need to store per  
shim context state. It just needs to be aware of the prefixes available  
in the site.

If we move to a foll locator selection proxy as you mention, we require  
per shim6 context state in the proxy, agree?

> To me, a full locator selecting proxy would do the entire shim6
> negotiation, keep the locator sets internally, choose *both* the source
> and destination locators to use, and supply preferences to the far  
> side to
> influence which ones it uses.  IOW, it would perform *all* the  
> functions
> of the shim.  This is substantially different from just rewriting  
> source
> address,

agree that is different

>  which doesn't give you any additional TE control unless it
> influences the far side's destination locator selection.
>

but it does provides additional TE control by allowing the selection of  
the site exit path for a given destiantion, agree?

>> the benefit of doing it this way as opposed to provide hints to the
>> hosts about which source address to use, is that the management of the
>> policy is in the scope of the routing system/admin, rather than in the
>> hosts themselves, which seems to be an important management issue for
>> some sites.
>
> In order for the routing system/admin to have full TE control, he would
> have to be in control of the choice of destination locator.  By the  
> time
> he gets the packets, it's too late for that, and all he can do is  
> rewrite
> the source locator

so far agree

> and hope that his rewriting sufficiently influences the
> end hosts so that they switch to using the locators preferred by the
> router.
>

but the effects of rewriting the source address are more important that  
just that, since it allows the routing system to actually select the  
exit path for that destiantion

>>> If you're going to do a full proxy, you have to go all the way IMO.
>>> That means that for whatever locators the end hosts use, whether they
>>> have multiple locators are not, have to be assumed to be fixed for  
>>> the
>>> session, just like ULIDs.  The shim6 proxy would then intercept all
>>> shim6 control traffic to that IP, and perform the shim functions on
>>> behalf of the host. It would have a bunch of its own locators, which
>>> would make up the locator set.  It could also include the ULID as one
>>> of those locators, and intercept traffic to that IP with shim6
>>> headers, or I suppose it could treat the host's IP as a non-routable
>>> identifier for shim6 purposes and just use its own locators in the
>>> locator set.  Either way, the proxy would process all shim6-tagged
>>> traffic for the host, de-shim it as normal, and then pass the traffic
>>> along to the host's IP instead of passing it up to the ULP.
>>>
>>> Does that sound reasonable?  What problems do you see with such a
>>> setup?
>>
>> well at least one issue that needs to be addressed in this model is
>> about address delegation.
>> i mean, the shim6 security is based on using HBAs and/or CGAs.
>> This means that at least the address that is going to be used in the
>> host must be a CGA or an HBA set.
>
> Couldn't the security simply be moved from the end host to the shim6
> proxy?  You're still assuming end-to-end shim6 security, but if the end
> host doesn't speak shim6 in the first place, the logical place for  
> shim6
> HBA/CGA security is not on the end host, but on the proxy where shim6  
> is
> actually being performed.

Yes, but that host needs to have at least one address, right?

And this address will be ULID used in the end to end shim6 context,  
right?

So, if this is so, then this address needs to be whether a HBA or a  
CGA, hence my previous comment applies.

That is, in the case of the HBA, it would be possible for the proxy to  
generate the HBA set and use something like dhcp to delegate the  
address to the host

Now, the host is not aware that there is anything special in that  
address(es) but the proxy knows that they form an HBA set, so he can  
use them in the  shim6 protocol interchangeably as locators.

If the CGA approach is used, it is a bit more complex, since the ULID  
must be a CGA. Again the proxy can generate it, and delegate it to the  
host using dhcp. Now, since the proxy is aware of the private key of  
the CGA it can perform the shim6 protocol. But in this case, we still  
need to figure out what would happen if the host needs to use the CGa  
for some other protocol (e.g. SeND)

>
>> In the HBA case, the problem could be addressed if the host obtains  
>> the
>> addresses from the proxy (e.g. using dhcp) and it configures the whole
>> HBA set. The point here is that the host cannot have any other
>> addresses, because if he use the other addresses, then the proxy won't
>> be able to run the shim6 protocol with those
>>
>> If we are using CGAs, then the proxy needs to be aware of the private
>> key associated with the CGA (and the CGA parameter data structure) or
>> we could define some form of delegating rights from the host to the
>> proxy.
>
> I'm working under the assumption that the end host *doesn't* do HBA or
> CGA, but instead just does IPv6 with a single address (for each
> connection).

yes but this address will be the ULID used in the shim6 contexts hence  
it msut be part of the HBA set or a CGA, see above

>  In this case the shim6 proxy would contain the entire
> HBA/CGA set, and would perform all the security functions on behalf of  
> the
> host.  Since the host doesn't even know that this shim6 thing exists,  
> he
> doesn't have to do anything special security-wise.
>
>> In any case, we need to figure out how this interacts with other host
>> based protocols that also use CGAs, like how do you run this with SeND
>
> I can't say I understand CGAs well enough to comment on the  
> implications
> of this...
>
>>> The most obvious one is that if you use the host's actual IP as one
>>> of the locators, you risk missing some shim6-tagged traffic if there
>>> is more than one route to the host.
>>
>> yes, but this is in the nature of the proxy approach, i mean, clearly
>> the shim would become a single point of failure in this case, but i  
>> see
>> this as inherent of a solution of this type, and it still provides  
>> some
>> additional fault tolerance for these hosts that don't support the  
>> shim6
>> protocol
>
> Yes, I would agree.  And the more we talk about it, the more I think  
> that
> a full shim6 proxy has to maintain the full locator set locally, and  
> just
> treat the hosts's IP as a non-routable ULID, not as an additional  
> locator.
>

ok, but in this case you would need a non routable prefix to assign non  
routable ULIDs, ULAs? and you would be loosing some referal callback  
support in this case.

Regards, marcelo

>>>   That could be alleviated by only using local locators in the  
>>> locator
>>> set, and treating the host's IP as an unroutable locator in shim6.
>>> If you did that, I guess there's the same problem I complained about
>>> in Erik's esd draft, which is that the host at the other end is  
>>> forced
>>> to shim6-tag all packets and maintain shim6 state for the duration of
>>> the session.
>
> -Scott
>

Delivery-date: Wed, 05 Apr 2006 06:31:03 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE
Date: Wed, 5 Apr 2006 09:30:16 +0300
To: Pekka Savola <[email-masked]>

Hi Pekka,

El 31/03/2006, a las 12:28, Pekka Savola escribió:

> Hi,
>
> Reading the extended shim design draft, in particular the discussion 
> on app modifications to do SRV lookup triggered the following thought.
>
> I'm pretty sure someone must have run this thought experiment before, 
> so pointers would be useful if so.
>

well, i don' recall hearing this before, not in the multi6/shim6 forums

> When applications perform DNS lookups and get multiple responses, the 
> _resolver libraries_ could, based on transparent (to the app) SRV 
> lookups or policy database, "weigh" the getaddrinfo responses given to 
> the applications.  That is, because the apps by default try the 
> addresses in the order they get them from getaddrinfo, instead of 
> returning the records in round-robin fashion, the resolver could very 
> well return certain addresses first (e.g.,) 90% of the time, some 
> others 10%.  (The obvious other address destination selection criteria 
> should be applied first.)

This seems like a good idea to me indeed. This would require only 
updating the resolver and relying on the apps querying for SRV records
However, SRV records have this Service.Proto.Name format that may not 
be the most appropriate for the shim6 needs, so perhaps it would make 
sense to define a new record type that has similar weight priority 
information, but that it has a node scope, i.e. does not depends of a 
service in particular.

I mean, since the SRV record has this special name associated, it may 
not trivial for the resolver to figure out which SRV record to query if 
the application wants to initiate a communication with machine1.foo.com

so perhaps it makes sense to go all the way and use new RR

>
> This would not have any negative impact on the application as all the 
> addresses would still be there but the ordering would just be modified 
> based on preferences, though running transparent SRV lookups could 
> incur delays etc. if it's not done in parallel.
>

> This could be very effective means for outbound TE decisions without a 
> need to touch applications at all.
>

well, actually i see it exactly the opposite :-)
this is really useful for inbound TE

I mean, outbound TE is the easy part, since the multihomed site is in 
control of the packets and it can route them however it wants to. So, 
outbound TE can be done by affecting routing or by configuring the 
source address selection policy table and so on.

The difficult part is how to influence incoming packets, that are not 
in our scope. This is where the SRV records and all this stuff becomes 
useful

> This doesn't really help with inbound TE though.  (One could add 
> similar function the site's authoritative DNS server, and unmodified 
> resolvers might comply with that policy, but caching DNS servers would 
> mess this up.)
>

why?
i agree that the expressed policy has to be quite stable, i mean, the 
cache will introduce certain inertia, and changing the preferences may 
take some time, but at least you can express some preferences about 
which addresses the site preffers for incoming communications...

> One could imagine that a part of inbound TE (for sessions which 
> originate at the site) could be handled with slightly similar source 
> address selection policies, but this doesn't help with inbound TE for 
> traffic originated from the Internet (but you could add the SRV 
> records or whatever if you care about this).
>

well, the idea is that resolvers do care about this and they will do 
this processing.
What is needed next is to see how to combine this with the local 
preferences...

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, 05 Apr 2006 06:10:20 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt
Date: Wed, 5 Apr 2006 09:09:11 +0300
To: Pekka Savola <[email-masked]>

Hi Pekka,

thank you very much for this in-depth review, i will try to address oem 
of your comments...

El 31/03/2006, a las 12:11, Pekka Savola escribió:
>
> substantial
> -----------

> 2) carrying the context tag opens the avenue for time-shifting attacks
> (e.g., data insertion into a session) after an attacker has moved from
> on-path to off-path ?
>

Well, i guess that what needs to be analyzed is the scope of this 
time-shifted attacks that you are considering. In other scenarios like 
MIP, the time-shifted attacks that have been considered as criticial 
are the redirection time-shifted attacks, where the attacker manages to 
be able to add new locator to the locator set after he has left the on 
path location. This means that the attacker that once was on the path 
is able to redirect the traffic after he has left the on path location. 
This is a serious attack and it is not possible to do that in the shim6 
protocol (thanks to the HBA/CGA protection)

However, as you mention, there are some time-shifted attacks that would 
be possible. In particular, it would be possible for an attacker that 
once was on the path to send a payload message that is protected by the 
context tag. This means that the attacker can insert data packet inside 
an established communication. This has the same effect of sending 
packets with spoofed source address, right? Currently the only defense 
against this is ingress filtering, which may or may not be deployed. 
With the shim solution, the attacker needs to be on path and catch at 
least one of the packets that carry to context tag. Then it can leave 
the path and he will be able to inject packets that the shim layer will 
translate into the proper source address. I would argue that it is 
probably easier to try to send packets with the spoofed source address 
than trying to intercept one of the shim6 establishment packets and 
then move away and inject packets in an ongoing communication. 
Especially, considering that those packets are likely to be discarded 
by higher layers, since they do not belong to any established 
communication. My perception of this is that the threat is similar to 
the current situation, if not less. Note that this could be easily 
solved by checking that the source locator is included in Ls(peer) but 
this has several difficulties in its own in the protocol functioning, 
and it doesn't seem to be worthy imho

>
> 3) The spec IMHO needs to say more about application framing impacts, 
> as a
> result of adding the shim to some packets (well, we have been rather 
> vague
> about this in the past, RFC4038 sec 5.4.2).  TCP-like protocols are 
> not a
> big problem because the stack can just adjust to whatever value is
> appropriate, but protocol such as UDP where the user needs to specify 
> this
> are trickier.  You should probably describe the required modifications
> to the implementations fragmentation handling code.
>
> Triggered by this text, but there was also discussion in 11.1 as well 
> as
> section 15, but the more appropriate place for discussing it
> should be a new section 11.2 ?
>
>    Layering the fragmentation header above the multihoming shim makes
>    reassembly robust in the case that there is broken multi-path 
> routing
>    which results in using different paths, hence potentially different
>    source locators, for different fragments.  Thus, effectively the
>    multihoming shim layer is placed between the IP endpoint sublayer,
>    which handles fragmentation, reassembly, and IPsec, and the IP
>    routing sublayer, which selects which next hop and interface to use
>    for sending out packets.
>
> 4) There seem to be a number of minor attacks, and/or non-issues or 
> residual
> threats which might be good to spell out better in the security
> considerations sections.
>
>  4.1) The only hash input that an attacker could not affect is the 
> secret
> value, and even that is static.  As the responder nonce is basically
> incremented based on the shim exchanges of the responder, the attacker 
> can
> predict that as well.  With this kind of information,
> (after some tries, and possibly other ways of obtaining knowledge how 
> long
> the host has been up) a) the attacker should be able to figure out the
> secret as well, and b) given that the attacker can choose so many bits 
> in
> the hash function input, it should be reasonable to find hash function
> collisions as well (especially with weaker hash functions).
>
> That said, both of these issues may be no-op's because the value of the
> information protected is not very high.

rather than the information protected is not very high, i would say 
that it would be easier for the attacker to actually send the I1 
messages and get new validators from the peer, rather than doing all 
this work,

>   But these considerations should be
> spelled out.
>

Agree, i guess we could also mention that the secret value could also 
be changed from once in a while making this attractive this attack, 
since the secret obtained would only be valid for a limited lifetime

>  4.2) what about the scenario where the initiator wishes to establish 
> shim6
> sessions when the other party isn't (yet) willing to do so? (Think 
> about
> large content providers.)  What are the graceful mechanisms to achieve 
> this?
>

I am not sure why this is a security concern...
but as currently defined, the peer that it is not willing to initiate a 
shim context could simply drop the I1 messages, that will be 
retransmited a couple of times and then the initiator will move this 
context to E-failed state, where it will stay for a period. After that, 
it will move to IDLE state and retry again.
If he wants to be left alone for a longer period, it could reply with a 
ICMP error, so the initiator will move to NO-SUPPORt state and stay 
there for even longer.

Would this be enough or do you think better support is required?

>  4.3) Following from 4.2), you really don't need the 4-way handshake 
> under
> normal circumstances.  When you wish to establish the shim6 state, the 
> peer
> has already proven its desire for genuine communication by opening the 
> TCP
> connection and using it for some time.  If it wanted to attack, it 
> wouldn't
> be using SHIM at all, just TCP.  So, you might be able to simplify the 
> SHIM
> exchange under normal situations.  On the other hand, the responders 
> need
> the mechanisms to deal with the cases where they don't want to 
> establish
> shim6 state yet (e.g., before the TCP connection is even established, 
> or
> whatever), or want to use a secure SHIM exchange variant.

well, this was discussed in the AMS interim meeting and actually i 
proposed that we could take an approach similar to IKEv2, where they 
fall back to require a prior contact proof in the case the node 
considers to be under attack.

So by default, context estbalishment would consists only in I2 and R2, 
and if the node considers to be under attack, it starts requiring the 4 
way exchange. The nice thing is that the I2 packet carries all the 
information required of the I1, so at the end, the 4 way exchenge would 
be I2,R1, I2, R2

The difficult part is how to detect that a node is under attack, 
especially if the resulting attack consists in 2 way exchange.
I mean, in the case of TCP 3 way exchange, an easy way to detect 
attacks is to measure the number of unfinnished TCP connection 
establishment. If the number is high, it is likely to be an attack.
In the case of a 2 way handshake, you don't have this possibility. In 
addition, the number of received connection requests may heavily vary 
from one small client to a big server, so it is hard to define a 
threshold to detect potential attacks.

Of course you can take into account what context are associated with 
exsiting TCP connections and consider that these ones are not part of 
the attack and so on. But in any case, i guess this is the tricky part.

In the AMS meeting, the proposal was to leave the 4 way handshake in 
the base spec and allow future extensions of the shim6 protocol for 
supporting this.
>
>  4.4) 47-bit context tags are the most troublesome issue to me.  You 
> should
> be more explicit what the effects of guessing (or knowing, from being 
> on the
> path) the tag are, 'cause disruption' is a bit vague.  The problem with
> these is that there is that from the network security manager's 
> perspective,
> there is no way to do any kind of filtering on the received packets -- 
> IP
> addresses, port numbers, etc. lose their relevancy when protecting 
> hosts
> from the big bad world.  Some may even consider this a feature...
>

agree, we could include some words in the line that i wrote above, 
would that be ok?

>
>
>
> semi-substantial (not sure if these are real issues or not)
> ----------------
>
>               ------------- R1 --------------->
>        Left old context
>        in ESTABLISHED
>
> ==> at this point, I kept thinking, "so.. isn't there any timeout for
> contexts in ESTABLISHED state..?  Does it stay there forever?"
>

section 9.  Teardown of the ULID-Pair Context deals with this point and 
it is left open to the implementations how to decide when perform 
garbage collection. Some guidelines are provided though...
...
    Thus it is RECOMMENDED that implementations minimize premature
    teardown by observing the amount of traffic that is sent and received
    using the context, and only after it appears quiescent, tear down the
    state.  A reasonable approach would be not to tear down a context
    until at least 5 minutes have passed since the last message was sent
    or received using the context.

do you think that additional guidance is needed?

>    Next the host verifies that the Responder Nonce is a recent one, and
>    that the Responder Validator option matches the validator the host
>    would have computed for the ULID, locators, responder nonce, and 
> FII.
>
> ==> how do you define 'a recent one' ?
>

this is also up to the implementations, but are you suggesting we 
provide some guidance about the lifetime of a responder nonce? like a 
maximum nonce lifetime or similar?

>    If the host receives an ICMP error with "payload type unknown" (type
>    4, code 1) and the included packet is the I1 message it just sent,
>    then this is a more reliable indication that the peer ULID does not
>    implement shim6.  Again, in this case, the host should remember to
>    not try again to establish a context with that ULID.  Such negative
>    caching should retained for at most ICMP_HOLDDOWN_TIME, which should
>    be significantly longer than the previous case.
>
> ==> you should probably apply the same policy for certain other ICMP 
> errors,
> at least type 1 code 1 "Communication with destination administratively
> prohibited", implying the protocol may be filtered at the firewall.
>

ok for that error code, do you have another one in mind?

>
>
>
>
>
> semi-editorial
> --------------
>
>    Next Header:   NO_NXT_HDR (59).
>
> ==> I'd make this 'Normally...' or the like, so that it would be 
> clearer
> that it might be OK for future extensions (if any) to also put in some 
> other
> value if they wanted to.
>
>    The following options are defined for this message:
>
> ==> but this is not an exhaustive list.  Do you already specify 
> somehow how
> you will treat yet-to-be-specified options?  How do you parse the 
> options
> that are not on the lists?
>

well, all the options have to have the format defined in section 5.14 
whcih is basically a TLV format. In addition, it contains the C flag, 
that defines whether the option is criticial or not and if it must be 
recognized.
what do you think that something is missing?

>    All of the TLV parameters have a length (including Type and Length
>    fields) which is a multiple of 8 bytes.  When needed, padding MUST 
> be
>    added to the end of the parameter so that the total length becomes a
>    multiple of 8 bytes.  This rule ensures proper alignment of data.  
> If
>    padding is added, the Length field MUST NOT include the padding.  
> Any
>    added padding bytes MUST be zeroed by the sender, and their values
>    SHOULD NOT be checked by the receiver.
>
> ==> I think this specification of padding adding is sub-optimal: why 
> do you
> say "the Length field MUST NOT include the padding" at all?  Do you 
> want to
> cover the scenario where the length field says X, but there is Y (>>X)
> amount of extra padding?  Specifying that padding up to 8 bytes can be
> stated in much simpler terms.
>
> 7.3  Normal context establishment
>
>    The normal context establishment consists of a 4 message exchange in
>    the order of I1, R1, I2, R2 as can be seen in Figure 24.
>
>         Initiator                          Responder
>
>          IDLE                               IDLE
>               ------------- I1 -------------->
>          I1-SENT
>               <------------ R1 ---------------
>                                             IDLE
>               ------------- I2 -------------->
>
> ==> at this point, I wondered, "how can the responder stay idle?  it 
> needs
> to remember _something_", so maybe a forward pointer to the security
> discussion (i.e., a global secret value) could be useful.
>

ok

>    We assume that all the incoming packets that trigger the generation
>    of an R1bis message contain a locator pair (in the address fields of
>    the IPv6 header) and a Context Tag.
>
> ==> there is no need to "assume" anything, as this should already 
> happen due
> to the nature of shim6.  Reword e.g., "The locator pair is extraced 
> from the
> source and destination IP addresses" or whatever.
>

well, this is in the case that new message formats are defined. We are 
assuming that they will contain the context tag. In this case, if they 
don't contain the context tag, it won't be possible to properly 
generate the R1bis packet...

> The Update Request message can include
>    just a Locator List option, to convey the new set of locators (which
>    requires a CGA signature option as well), just a Locator Preferences
>    option, or both a new Locator List and new Locator Preferences.
>
> ==> The CGA signature options is only applicable w/ new locators when 
> you
> use non-HBA CGA addresses, right?
>

yes, but it would be somehow strange to add new locators if you use 
HBAs, right? i mean, if you use HBAs the locator set is static. You 
could just include a subset on the HBA set in the locator set option 
initially exchanged and later on add new locators of the set, i guess, 
but i am not sure if this makes much sense, but we could add a 
clarification about this point if you think it would be useful

>   Should there be no response, the retransmissions continue forever.
>    The binary exponential backoff stops at MAX_UPDATE_TIMEOUT.
>
> ==> "forever" is a rather harsh way to say that.  "until the shim 
> state is
> discarded" or something?

yes forever seems a bit long i guess

>
>   I1_RETRIES_MAX
>
> ==> you didn't specify the constant...
>

ok

>
>
>
>
>
>
> editorial
> ---------
>
>                    Level 3 multihoming shim protocol
>
> ==> how about "Layer 3 Multihoming Shim Protocol for IPv6" ?
>

well, v4 locator extensions are being proposed....

>    The SHIM6 protocol is a layer 3 shim for providing locator agility
>    below the transport protocols, so that multihoming can be provided
>    for IPv6 with failover and load sharing properties, without assuming
>    that a multihomed site will have a provider independent IPv6 address
>    prefix which is announced in the global IPv6 routing table.
>
> ==> the latter part is not important for this spec, so almost the same 
> thing
> would be to say:
>
>    The SHIM6 protocol is a layer 3 shim for providing locator agility
>    below the transport protocols, so that multihoming can be provided
>    for IPv6 with failover and load sharing properties, without assuming
>    that a multihomed site will have a globally routable provider
>    independent IPv6 address prefix.
>

well, i think it is important to stress that what we want to avoid is 
announcing specific prefixes for multihomed sites, which is clearer in 
the current writing imho, what is in the proposed rephrasing that you 
want to improve?

> ...
>
>    The reachability detection and failure detection, including how a 
> new
>
> ==> remove the first "detection" as unnecessary.

ok
>
>    o  Do not require an extra roundtrip up front to setup shim specific
>       state.
>
> ==> remove "Do" for style consistency?
>
> But it is not a goal to try to make communication
>    survive a renumbering event (which causes all the locators of a host
>    to change to a new set of locators).  This proposal does not attempt
>    to solve the, perhaps related, problem of host mobility.
>
> ==> s/proposal/proposal also/ ?
>

neither?

>    Worst case we could end up with two separate hosts using the same
>    ULID while both of them are communicating with the same host.
>
> ==> s/Worst/In the worst/
>

ok

>    The proposal uses an multihoming shim layer within the IP layer,
>
> ==> s/an/a/
>

ok

>    2), there is a choice whether the shim applies inside the tunnel or
>    outside the tunnel, which effects the location of the shim6 header.
>
> ==> s/effects/affects/
>

ok
>    The responder can choose exactly what input uses to compute the
>    validator,
>
> ==> s/uses/is used/
>

ok

> 7.1  Uniqness of Context Tags
>
> ==> s/Uniq/Unique/
>

ok

>         Host A                             Host B
>
>          IDLE                               IDLE
>               -\
>          I1-SENT---\
>                     ---\                  /---
>                         --- I1 ---\   /---  I1-SENT
>                                    ---\
>                        /--- I1 ---/    ---\
>                   /---                     -->
>               <---
>
> ==> could this look nicer if the diagrams were drawn with more
> straight lines, like:
>
>                 IDLE                          IDLE
>                      -----------.
>                                  \      .-----
>                                   I1   I1
>                                     \ /
>                                      X
>                                     / \
>                                        '----->
> ...
>
>    If the host receives an ICMP error with "payload type unknown" (type
>    4, code 1) and the included packet is the I1 message it just sent,
>
> ==> in a couple of places, the error name is actually "Unrecognized 
> Next
> Header type encountered".
>
ok

>    If any of the above verifications fails, then the host silently
>    discard the message and it has completed the I2 processing.
>
> ==> s/discard/discards/
>

ok

>    o  The HBA technique [7] for verifying the locators to prevent an
>       attacker from redirecting the packet stream to somewhere else.
>
>    o  Requiring a Reachability Probe+Reply before a new locator is used
>
> ==> if you want consistent style, I'd s/for verifying/verifies/,
> s/Requiring/Requires/ (not sure about this one...)
>
>    specification.  Special thanks to the careful comments from Geoff
>    Houston and Shinta Sugimoto on earlier versions of this draft.
>
> ==> s/Houston/Huston/
>

ok

> Appendix C.  Change Log
>
> ==> add a note to the rfc-editor to remove this upon publication (it 
> would
> actually be best if this was the last appendix, so the appendix numbers
> wouldn't get shuffled when this gets removed.)
>

ok

thanks, 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: Tue, 04 Apr 2006 16:03:11 +0000
Date: Tue, 4 Apr 2006 12:02:55 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

On 04/04/06 at 2:16pm +0300, marcelo bagnulo braun <[email-masked]> wrote:

> > I disagree with this.  If a rewriting-capable host, which may or may
> > not have a rewriting router on the path, started up communication
> > observing these SHOULDs, then the host it's talking to, which may be a
> > very busy non-multihomed (or PI-multihomed) server, would have to keep
> > full shim6 context and would be unable to discard it during
> > communication due to the presence of shim6 extension headers on every
> > packet.  This would be true even if no source-rewriting routers were
> > deployed, and no one gained any benefit from the capability.
> >
> > IMO a better approach would be to continue using deferred context
> > establishment (except in the identifier/locator split case, of
> > course), and initially only put the Sent Locator Pair option packets
> > that already have shim6 headers (shim6 control packets and any packets
> > sent with non-ULID locators).  Then, *if* source locator rewriting is
> > done by a router on *those* packets, you can start putting shim6
> > extension headers on all ULP payload packets.
>
> I guess that what you want is first to discover if there is router
> rewriting in the path and if this is so, then enable this capability for
> the particular shim6 context.

Yes, I agree.  We just have to figure out how to do that.  :)

> The problem that i see with this is that i don't think it is trivial to
> detect if a rewriting router is in the path. In particular, i don't
> think that the context establishment exchange is enough to detect such
> presence, especially because it may well happen that during the context
> establishment exchange, the source address match with what the router
> would have rewritten, and even if there is a rewriting router in the
> path, the source address is unchanged.

That is true.  BUT, if the router doesn't need to rewrite the source
address, is there a need for shim6-tagging every packet?  IOW, if the
hosts are already doing what the router wants them to, it can just sit
back and let them continue.

Now I suppose the router might change its TE preferences in mid-session,
and want to start rewriting locators.  But in that case, I think it could
just do so on shim6 packets, leaving the non-shim6-tagged packets alone as
it would have to do for non-shim6-capable hosts.  That way all new flows
could be rewritten and redirected, without impacting hosts that aren't
shim6-capable, or hosts that don't want to keep all their shim6 state.
(In fact, there's no difference between the two as far as a router is
concerned.)

> I guess it hard to have both aggressive garbage collection and source
> address rewriting and i guess each site will prefer one capability
> over the other. So i guess that the best we could do is to provide
> tools so that each site can benefit from the capability that it
> prefers the most.

I agree.  And in order to do so, we have to ensure that the decisions of
one site (say a multihomed small site) to *support* source address
rewriting doesn't automatically impact all the shim6-capable hosts it
talks to.  Rather, we need to make sure that the only time we require both
sides to keep full shim6 context is when a router in the path has already
performed source locator rewriting.

-Scott

Delivery-date: Tue, 04 Apr 2006 15:47:02 +0000
Date: Tue, 4 Apr 2006 11:46:53 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Erik Nordmark <[email-masked]>
Subject: Re: Possible modification to the shim6 base spec (was:Re: Shim6 failure recovery after garbage collection)

On 04/04/06 at 1:17pm +0300, marcelo bagnulo braun <[email-masked]> wrote:

>
> El 30/03/2006, a las 21:42, Scott Leibrand escribió:
> >> Do you see any problems with this behaviour?
> >
> > Yes, I do.  Say you have a one-way data transfer, from a busy server
> > that aggressively garbage-collects shim6 context to a multihomed shim6
> > client. The client at some point establishes shim6 context, which the
> > server promptly discards.  The client requests a bunch of data, which
> > the server sends.  The last data packet from the server clears the
> > keepalive timer, but it is restarted again when the client ACKs the
> > last packet.  Since the server has no more data to send, the keepalive
> > timer expires.  This prompts the client to send a shim6 keepalive,
> > which in turn generates an R1bis message and re-establishes the
> > context.  IMO this unnecessary context re-establishment could pose a
> > problem for sites who can't afford any additional state on their
> > servers, especially if it happens repeatedly and prevents the server
> > from garbage-collecting the state a second time.
>
> yes, i remember Jari commenting something about this issue, that it
> seems that a couple of additional packets were needed to finish the
> process... And yes, this seems to have bad impact on this case where
> server's aggressively garbage collect
>
> So i agree this is an issue...
>
> I wonder if it would be ok not to send R1bis as reply to keepalive
> message, (but send it as a reply to probe messages)
>
> In this case, the reception of a keepalive wouldn't trigger a R1bis,
> which would deal with this case.

But wouldn't the lack of a keepalive cause the keepalive timer on the
sending side to time out?

> In the case that the lost context needs to be recovered, the impact is
> that this is delayed until the peer decides to perform an
> exploration...

And wouldn't the expiration of the keepalive timer trigger an exploration?

> Do you think this would be a good approach?
>
>
>
> >> OTOH, it may make sense to explicitly state in the draft what a
> >> payload packet is...
> >
> > Yeah, I think we need to at least talk about it there, as it seemed
> > rather ambiguous to me.
>
> In the failure detection draft you mean, right? (not in the shim6 proto
> spec)

Wherever it is we define behavior based on payload packets, we should
define such packets.  I don't recall which draft that's in...

-Scott

Delivery-date: Tue, 04 Apr 2006 15:44:40 +0000
Date: Tue, 4 Apr 2006 11:44:02 -0400 (EDT)
From: Scott Leibrand <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: Shim6 proxies

On 04/04/06 at 11:21am +0300, marcelo bagnulo braun <[email-masked]> wrote:

>
> El 30/03/2006, a las 19:46, Scott Leibrand escribió:
>
> > On 03/28/06 at 8:57am +0300, marcelo bagnulo braun
> > <[email-masked]> wrote:
> >
> >> - on one hand, a proxy that basically performs locator selection on
> >> behalf of the host. In this case, the security functions are still end
> >> to end, but the locator selection is performed by another device,
> >> likely a router, that has more information about available routes
> >> and/or is managed by the network admins. This is basically what is
> >> described in draft-nordmark-shim6-esd-00.
> >
> > That's not the impression I got.  It looks to me like
> > draft-nordmark-shim6-esd-00 provides similar functionality, in that
> > the routers can provide hints to the shim6 hosts that certain locators
> > would be preferred, but they don't actually perform the locator
> > selection in any direct manner...
>
> not sure what part are you referring to, but i was talking section  3.4
>    Locator Rewriting by Routers , which basically extends the shim6
> protocol so that exit routers rewrite the source locator. This basically
> implies offloading the source locator selection to the site exit
> routers, agree?

Yes, but since source locators aren't used for routing (just for
filtering), to me that's less important than the influence the source
locator rewriting has on the choice of destination locator on the return
path.

> >> This seems an architecturally clean approach, since the locator
> >> selection function can be cleanly off loaded from the host itself, as
> >> long as the security remains e2e.
> >
> > Perhaps, but I'm not sure what benefits a locator-selecting proxy
> > would have over simply rewriting the source locators in each
> > direction, thereby providing hints to the shim6-capable hosts of what
> > they should do.
>
> i am not sure if i following you... for me
>
> locator selecting proxy == rewriting source address by exit routers

That's not how I see it.  Since the source locator doesn't influence the
path a packet takes, source locator rewriting matters most for getting
through source-address filters, and secondarily for influencing the end
hosts to use a different destination locators than they might otherwise.

To me, a full locator selecting proxy would do the entire shim6
negotiation, keep the locator sets internally, choose *both* the source
and destination locators to use, and supply preferences to the far side to
influence which ones it uses.  IOW, it would perform *all* the functions
of the shim.  This is substantially different from just rewriting source
address, which doesn't give you any additional TE control unless it
influences the far side's destination locator selection.

> the benefit of doing it this way as opposed to provide hints to the
> hosts about which source address to use, is that the management of the
> policy is in the scope of the routing system/admin, rather than in the
> hosts themselves, which seems to be an important management issue for
> some sites.

In order for the routing system/admin to have full TE control, he would
have to be in control of the choice of destination locator.  By the time
he gets the packets, it's too late for that, and all he can do is rewrite
the source locator and hope that his rewriting sufficiently influences the
end hosts so that they switch to using the locators preferred by the
router.

> > If you're going to do a full proxy, you have to go all the way IMO.
> > That means that for whatever locators the end hosts use, whether they
> > have multiple locators are not, have to be assumed to be fixed for the
> > session, just like ULIDs.  The shim6 proxy would then intercept all
> > shim6 control traffic to that IP, and perform the shim functions on
> > behalf of the host. It would have a bunch of its own locators, which
> > would make up the locator set.  It could also include the ULID as one
> > of those locators, and intercept traffic to that IP with shim6
> > headers, or I suppose it could treat the host's IP as a non-routable
> > identifier for shim6 purposes and just use its own locators in the
> > locator set.  Either way, the proxy would process all shim6-tagged
> > traffic for the host, de-shim it as normal, and then pass the traffic
> > along to the host's IP instead of passing it up to the ULP.
> >
> > Does that sound reasonable?  What problems do you see with such a
> > setup?
>
> well at least one issue that needs to be addressed in this model is
> about address delegation.
> i mean, the shim6 security is based on using HBAs and/or CGAs.
> This means that at least the address that is going to be used in the
> host must be a CGA or an HBA set.

Couldn't the security simply be moved from the end host to the shim6
proxy?  You're still assuming end-to-end shim6 security, but if the end
host doesn't speak shim6 in the first place, the logical place for shim6
HBA/CGA security is not on the end host, but on the proxy where shim6 is
actually being performed.

> In the HBA case, the problem could be addressed if the host obtains the
> addresses from the proxy (e.g. using dhcp) and it configures the whole
> HBA set. The point here is that the host cannot have any other
> addresses, because if he use the other addresses, then the proxy won't
> be able to run the shim6 protocol with those
>
> If we are using CGAs, then the proxy needs to be aware of the private
> key associated with the CGA (and the CGA parameter data structure) or
> we could define some form of delegating rights from the host to the
> proxy.

I'm working under the assumption that the end host *doesn't* do HBA or
CGA, but instead just does IPv6 with a single address (for each
connection).  In this case the shim6 proxy would contain the entire
HBA/CGA set, and would perform all the security functions on behalf of the
host.  Since the host doesn't even know that this shim6 thing exists, he
doesn't have to do anything special security-wise.

> In any case, we need to figure out how this interacts with other host
> based protocols that also use CGAs, like how do you run this with SeND

I can't say I understand CGAs well enough to comment on the implications
of this...

> > The most obvious one is that if you use the host's actual IP as one
> > of the locators, you risk missing some shim6-tagged traffic if there
> > is more than one route to the host.
>
> yes, but this is in the nature of the proxy approach, i mean, clearly
> the shim would become a single point of failure in this case, but i see
> this as inherent of a solution of this type, and it still provides some
> additional fault tolerance for these hosts that don't support the shim6
> protocol

Yes, I would agree.  And the more we talk about it, the more I think that
a full shim6 proxy has to maintain the full locator set locally, and just
treat the hosts's IP as a non-routable ULID, not as an additional locator.

> >   That could be alleviated by only using local locators in the locator
> > set, and treating the host's IP as an unroutable locator in shim6.
> > If you did that, I guess there's the same problem I complained about
> > in Erik's esd draft, which is that the host at the other end is forced
> > to shim6-tag all packets and maintain shim6 state for the duration of
> > the session.

-Scott

Delivery-date: Tue, 04 Apr 2006 11:16:49 +0000
Cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]
Date: Tue, 4 Apr 2006 14:16:14 +0300
To: Scott Leibrand <[email-masked]>

Hi Scott,

> I disagree with this.  If a rewriting-capable host, which may or may 
> not
> have a rewriting router on the path, started up communication observing
> these SHOULDs, then the host it's talking to, which may be a very busy
> non-multihomed (or PI-multihomed) server, would have to keep full shim6
> context and would be unable to discard it during communication due to 
> the
> presence of shim6 extension headers on every packet.  This would be 
> true
> even if no source-rewriting routers were deployed, and no one gained 
> any
> benefit from the capability.
>
> IMO a better approach would be to continue using deferred context
> establishment (except in the identifier/locator split case, of course),
> and initially only put the Sent Locator Pair option packets that 
> already
> have shim6 headers (shim6 control packets and any packets sent with
> non-ULID locators).  Then, *if* source locator rewriting is done by a
> router on *those* packets, you can start putting shim6 extension 
> headers
> on all ULP payload packets.
>

I guess that what you want is first to discover if there is s router 
rewriting in the path and if this is so, then enable this capability 
for the particular shim6 context.

The problem that i see with this is that i don't think it is trivial to 
detect if a rewriting router is in the path. In particular, i don't 
think that the context establishment exchenge is enough to detect such 
presence, especially because it may well happen that during the context 
estbalihsment exchenge, the source address match with what the router 
would have rewritten, and even if there is a rewriting router in the 
path, the source address is unchanged.

I guess it hard to have both aggresive garbage collection and source 
address rewriting and i guess each site will preffer one capability 
over the other. So i guess that the best we could do is to provide 
tools so that each site can benefit from the capability that it 
preffers the most.

Regards, marcelo

> My reasoning for wanting to make the changes above is that IMO there 
> will
> be a lot more users who want to minimize shim6 state on their servers 
> than
> who want to do shim6 rewriting in their routers, at least initially.  
> If
> we start requiring all packets between shim6-capable hosts to have 
> shim6
> extension headers, that requires that all shim6-capable hosts keep full
> shim6 state for all communications with other shim6-capable hosts, 
> which
> in turn means that operators of large servers will turn off shim6
> entirely, and it will be of very limited utility due to very limited
> deployment.
>
> -Scott
>
> On 03/01/06 at 11:45am -0800, Erik Nordmark <[email-masked]> 
> wrote:
>
>>
>>
>> -------- Original Message --------
>> Subject: I-D ACTION:draft-nordmark-shim6-esd-00.txt
>> Date: Tue, 28 Feb 2006 15:50:02 -0500
>> From: [email-masked]
>> Reply-To: [email-masked]
>> To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: Extended Shim6 Design for ID/loc split and
>>                            Traffic Engineering
>> 	Author(s)	: E. Nordmark
>> 	Filename	: draft-nordmark-shim6-esd-00.txt
>> 	Pages		: 25
>> 	Date		: 2006-2-28
>>
>>     The Shim6 protocol provides for locator agility while satisfying 
>> the
>>     'first, do no harm' security requirements.  This document outlines
>>     some extensions to Shim6 that in addition provides complete
>>     separation between identifiers and locators, and allows routers to
>>     rewrite the locators in the shim6 packets as a way to provide 
>> traffic
>>     engineering information to the hosts.
>>
>>     The document also outlines a simple extension to allow shim6, 
>> with a
>>     CGA upper-layer ID, to operate using IPv4 addresses as locators.
>>
>>     The purpose of this outline is to stimulate discussions.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the 
>> username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> 	"get draft-nordmark-shim6-esd-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-nordmark-shim6-esd-00.txt".
>>
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>

Delivery-date: Tue, 04 Apr 2006 10:18:28 +0000
Cc: shim6-wg <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Possible modification to the shim6 base spec (was:Re: Shim6 failure recovery after garbage collection)
Date: Tue, 4 Apr 2006 13:17:55 +0300
To: Scott Leibrand <[email-masked]>

El 30/03/2006, a las 21:42, Scott Leibrand escribió:
>> Do you see any problems with this behaviour?
>
> Yes, I do.  Say you have a one-way data transfer, from a busy server 
> that
> aggressively garbage-collects shim6 context to a multihomed shim6 
> client.
> The client at some point establishes shim6 context, which the server
> promptly discards.  The client requests a bunch of data, which the 
> server
> sends.  The last data packet from the server clears the keepalive 
> timer,
> but it is restarted again when the client ACKs the last packet.  Since 
> the
> server has no more data to send, the keepalive timer expires.  This 
> prompts
> the client to send a shim6 keepalive, which in turn generates an R1bis
> message and re-establishes the context.  IMO this unnecessary context
> re-establishment could pose a problem for sites who can't afford any
> additional state on their servers, especially if it happens repeatedly 
> and
> prevents the server from garbage-collecting the state a second time.
>

yes, i remember Jari commenting something about this issue, that it 
seems that a couple of additional packets were needed to finnish the 
process...
And yes, this seems to have bad impact on this case where server's 
aggressively garbage collect

So i agree this is an issue...

I wonder if it would be ok not to send R1bis as reply to keepalive 
message, (but send it as a reply to probe messages)

In this case, the reception of a keepalive wouldn't trigger a R1bis, 
which would deal with this case.
In the case that the lost context needs to be recovered, the impact is 
that this is delayed until the peer decides to perform an 
exploration...

Do you think this would be a good approach?

>> OTOH, it may make sense to explicitly state in the draft what a 
>> payload
>> packet is...
>
> Yeah, I think we need to at least talk about it there, as it seemed 
> rather
> ambiguous to me.

In the failure detection draft you mean, right? (not in the shim6 proto 
spec)

regards, marcelo

>
> -Scott
>

Delivery-date: Tue, 04 Apr 2006 08:22:32 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Tue, 4 Apr 2006 11:21:33 +0300
To: Scott Leibrand <[email-masked]>

El 30/03/2006, a las 19:46, Scott Leibrand escribió:

> On 03/28/06 at 8:57am +0300, marcelo bagnulo braun 
> <[email-masked]> wrote:
>
>> Hi Scott,
>>
>> This topic has been discussed several times on this ml.
>
> Cool.
>
>> My understanding of this topic is that there can be basically two
>> flavors of proxy-like devices:
>> - on one hand, a proxy that basically performs locator selection on
>> behalf of the host. In this case, the security functions are still end
>> to end, but the locator selection is performed by another device,
>> likely a router, that has more information about available routes
>> and/or is managed by the network admins. This is basically what is
>> described in draft-nordmark-shim6-esd-00.
>
> That's not the impression I got.  It looks to me like
> draft-nordmark-shim6-esd-00 provides similar functionality, in that the
> routers can provide hints to the shim6 hosts that certain locators 
> would
> be preferred, but they don't actually perform the locator selection in 
> any
> direct manner...

not sure what part are you referring to, but i was talking section  3.4 
   Locator Rewriting by Routers , which basically extends the shim6 
protocol so that exit routers rewrite the source locator. This basiclly 
implies offloading the source locator selection to the site exit 
routers, agree?
>
>> This seems an architecturally clean approach, since the locator
>> selection function can be cleanly off loaded from the host itself, as
>> long as the security remains e2e.
>
> Perhaps, but I'm not sure what benefits a locator-selecting proxy would
> have over simply rewriting the source locators in each direction, 
> thereby
> providing hints to the shim6-capable hosts of what they should do.

i am not sure if i following you... for me

locator selecting proxy == rewriting source address by exit routers

the benefit of doing it this way as opposed to provide hints to the 
hosts about which source address to use, is that the management of the 
policy is in the scope of the routing system/admin, rather than in the 
hosts themselves, which seems to be an important managment issue for 
some sites.

>
>>  - on the other hand, there is the full proxy. this was discussed
>> several times (most of times by Iljitsch). In this case, there is a
>> proxy that establishes shim contexts on behalf of a non-shim capable
>> node. In this case, the proxy performs all the functions of the shim.
>
> This is more what I was thinking.
>
>> Now, this seems to be an useful tool, especially for facilitating the
>> deployment and providing some benefits of the shim to legacy hosts.
>> However there seems to be certain questions that need to be answered 
>> in
>> this scenario. For instance, does the host has one or many addresses? 
>> i
>> mean is the host aware that it has multiple addresses or not? 
>> depending
>> on the assumption here, different problems appear. Let's start by this
>> point... what did you have in mind for this?
>
> If you're going to do a full proxy, you have to go all the way IMO.  
> That
> means that for whatever locators the end hosts use, whether they have
> multiple locators are not, have to be assumed to be fixed for the 
> session,
> just like ULIDs.  The shim6 proxy would then intercept all shim6 
> control
> traffic to that IP, and perform the shim functions on behalf of the 
> host.
> It would have a bunch of its own locators, which would make up the 
> locator
> set.  It could also include the ULID as one of those locators, and
> intercept traffic to that IP with shim6 headers, or I suppose it could
> treat the host's IP as a non-routable identifier for shim6 purposes and
> just use its own locators in the locator set.  Either way, the proxy 
> would
> process all shim6-tagged traffic for the host, de-shim it as normal, 
> and
> then pass the traffic along to the host's IP instead of passing it up 
> to
> the ULP.
>
> Does that sound reasonable?  What problems do you see with such a 
> setup?
>

well at least one issue that needs to be addressed in this model is 
about address delegation.
i mean, the shim6 security is based on using HBAs and/or CGAs.
This means that at least the address that is going to be used in the 
host must be a CGA or an HBA set.
In the HBA case, the problem could be addressed if the host obtains the 
addresses from the proxy (e.g. using dhcp) and it configures the whole 
HBA set. The point here is that the host cannot have any other 
addresses, becuase if he use the other addresses, then the proxy won't 
be able to run the shim6 protocol with those

If we are using CGAs, then the proxy needs to be aware of the private 
key associated with the CGA (and the CGA parameter data structure) or 
we coudl define some form of delegating rights from the host to the 
proxy.

In any case, we need to figure out how this interacts with other host 
based protocols that also use CGAs, like how do you run this with SeND

> The most obvious one is that if you use the hosts's actual IP as one of
> the locators, you risk missing some shim6-tagged traffic if there is 
> more
> than one route to the host.

yes, but this is in the nature of the proxy approach, i mean, clearly 
the shim would become a single point of failure in this case, but i see 
this as inherent of a solution of this type, and it still provides some 
additional fault tolerance for these hosts that don't support the shim6 
protocol

Regards, marcelo

>   That could be alleviated by only using local
> locators in the locator set, and treating the host's IP as an 
> unroutable
> locator in shim6.  If you did that, I guess there's the same problem I
> complained about in Erik's esd draft, which is that the host at the 
> other
> end is forced to shim6-tag all packets and maintain shim6 state for the
> duration of the session.
>
> -Scott
>
>> El 27/03/2006, a las 22:54, Scott Leibrand escribió:
>>
>>> Has there been any consideration of the interaction of the proposed
>>> shim6 protocol with a potential shim6 proxy?  I'm thinking it would 
>>> be
>>> quite useful to be able to place a device on-path near one end of a
>>> TCP connection (i.e. on the default router), and have the device
>>> perform shim6 functions (and possibly other multihoming duties) on
>>> behalf of one or more host(s) behind it.
>>>
>>> -Scott
>>>
>

Delivery-date: Tue, 04 Apr 2006 06:24:38 +0000
From: marcelo bagnulo braun <[email-masked]>
Subject: MIPv6-SHIM6 interaction (was Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt
Date: Tue, 4 Apr 2006 09:23:15 +0300
To: shim6-wg <[email-masked]>

Hi all,

In the SHIM6 wg meeting in Dallas, some people pointed out that we need 
to verify that SHIM and MIPv6 worked together in a reasonable way 
without interfering with each other. In order to verify that, the first 
thing to do is to identify the scenarios where they are likely to 
interoperate i.e. where there seems to make more sense to run MIP and 
shim togeether. After discussing this point with several people 
including Erik, Hesham, Vijay and Dave, the scenarios and use cases 
described below for a joint MIPv6-Shim6 operation have been identified.

(Note that this is merely my understanding of the topic, so only i have 
the responsibility for any mistake here)

In general terms, it is my understanding that MIP and SHIM interact 
properly in the the identified valuable scenarios, while some details 
may require some additional thought, especially in the last scenario.

1)- Multihomed home network. In this case, the Home Network of a mobile 
node is multihomed. This basically means that the home network has 
multiple prefixes/ISPs available, resulting in the MN having multiple 
HoAs, one per available prefix. In this case, it seems reasonable to 
expect that the MN can benefit from the multihoming features when it is 
roaming. So, this basically means that the MIPv6 protocol is used to 
support mobility of the MN when it is away from home and the Shim6 
protocol is used to provide multihoming support to all the nodes in the 
multihomed site, in particular to the MN. In other words, each protocol 
is used for its original purpose. This use case MUST work properly, 
since it is just the natural conjunction of both technologies. In this 
case, shim6 is layered above MIPv6 and below IPSec. So when a packet is 
coming from the application layer, it is firstly processed by IPSec, 
then by the SHIM and finally by the MIPv6. MIPv6 spec has some wording 
about how IPSec is processing, stating basically that IPSec is above 
MIPv6, which is architecturally coherent with this stack layout 
considered here. Probably some additional consideration are required, 
since the SHIM will lay between IPSec and MIPv6, but it is expected 
that the interaction can work properly. In this case, the available 
HoAs can form a HBA set so that a given communication can move from one 
HoA to another.
Overall, the mapping would be like this: the application sends a packet 
using the ULID pair (probably including a HoA). The packet is then 
processed by the shim layer, which it may map the ULID to an 
alternative pair if a outage has occurred. The alternative address, 
will also be a HoA. then, the packet is passed to the MIPv6 layer, 
which will perform the HoA CoA mapping (BT or RO modes)

2)- HA-MN tunnel fault tolerance. Consider the case where the HA has 
multiple addresses, whether because multiple prefixes are available or 
multiple interfaces. In addition, the MN may also have multiple 
addresses, because the visited network is multihomed and/or because the 
MN has multiple interfaces. In this case, the shim is used to provide 
additional fault tolerance to the tunnel path, the shim is used in the 
tunnel interface. In this case, the shim is associated to the tunnel 
interface and not to the IP interface that is running MIPv6. In this 
case, Shim is located below IPSec layer of the tunnel interface. Again 
the interaction in this case is architecturally clean. It may be 
possible to provide support for this case without using the shim. 
However, even in this case, it may make sense to reuse some of the shim 
mechanisms like the failure detection and path exploration mechanisms 
in an alternative MIPv6 based solution. So, this case MAY be supported 
but other configurations that rely only in MIP may result more 
attractive to provide the required features, reusing existing shim6 
mechanisms

3)- Shim6 based RO. This case is similar to the first scenario, only 
that CoAs are also presented to the shim. So in case of a failure, the 
shim may select a CoA as an alternative locator rather than a HoA. If a 
CoA is selected, then the outgoing packet needs not to be processed by 
the MIPv6 layer (no BCE is available) and the result is a shim6 based 
RO mode, where packet flows directly between the MN and the CN. While 
it seems to us that this is workable, at this point it is not clear to 
us how valuable is this configuration.

El 23/03/2006, a las 17:29, Geoff Huston escribió:

> Folks,
>
>         This note starts the WG Last Call for comments on
>         draft-ietf-shim6-proto-04.txt, "Level 3 multi-homing shim
>         protocol".
>
>         It can be found at:
>         
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-proto-04.txt
>
>         The document is intended to be submitted by the Working Group
>         to the IESG for publication as a Proposed Standard.
>
>         Please review the document carefully, and send your feedback 
> to the
>         SHIM6 list.  Please also indicate in your response whether or 
> not
>         you believe that this document is ready to go to the IESG.
>
>         This Last Call will end on Friday 14 Apr 2006 at 0800 AEST
>         (UTC+10).
>
>         Thanks,
>
>
>               Geoff & Kurtis
>
> ----------------------------------------------------------
>
> Additional comments to this Last Call:
>
> o The three week period for the WG Last Call is to allow some leeway 
> for
>   post-IETF recovery!
>
> o We also note that we have an outstanding topic of compatibility with
>   Mobile IPv6 and SHIM6 as discussed in the Working Group meeting this
>   week. This last call has been generated on the basis of verbal advice
>   provided by the document's editors that this matter has been 
> discussed
>   with Mobile IPv6 folk and that there are no serious issues of
>   incompatibility anticipated. I expect a note to this effect from 
> Marcelo
>   Bagnulo summarizing the outcomes of this discussion to be posted to 
> the
>   SHIM6 WG during this Last Call period.
>
> o We have consulted with the technical advisors to this Working Group 
> and
>   they have indicated that are happy for us to proceed with this last 
> call at
>   this time.
>
>
>