Subject: Fwd: shim6 @ NANOG (forwarded note from John Payne)
From: Iljitsch van Beijnum <[email-masked]>
To: shim6-wg <[email-masked]>
Date: Tue, 28 Feb 2006 23:41:51 +0100

[Just on shim6]

Begin forwarded message:

>>> Should be doable with a DNS SRV record like mechanism. Don't worry
>>> too much about this one.

>> Where does the assumption that the network operators control the  
>> DNS  for
>> the end hosts come from?

> Thin air I think.  Certainly isn't the case with a large number of  
> domains we host.

Well, I guess we'll have to dust off A6 records... Those were created  
for this exact purpose.

We were talking about traffic engineering here, but this problem  
applies to simply having multiple AAAA records too, to a lesser  
degree, which is a fairly important notion in what we're trying to do...

Delivery-date: Tue, 28 Feb 2006 22:13:38 +0000
Date: Wed, 01 Mar 2006 09:12:48 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)

Reposted on behalf of Iljitsch van Beijnum

(It appears that we have a rather aggressive mail list manager that eats 
messages with
control words such as "sub scribe")

   Geoff

>From: Iljitsch van Beijnum <[email-masked]>
>Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
>Date: Tue, 28 Feb 2006 13:31:36 +0100
>To: Jason Schiller ([email-masked]) <[email-masked]>
>
>[Crossposted to shim6 and NANOG lists, please don't make me regret
>this... Replies are probably best sent to just one list for people
>who don't sub scribe to both.]
On 27-feb-2006, at 22:13, Jason Schiller ([email-masked]) wrote:

 > Is it the consensus of the shim6 working group that the full suite
 > of TE
 > capabilities should not be a requirement?  Or is this just the
 > opinion of
 > a few vocal people?

I don't think I'm going out on a limb when I say that there is
consensus that we need good enough traffic engineering from the
start. (Where "start" means deployment, not necessarily the
publication of the first RFC.)

I think basic balancing of both incoming and outgoing traffic over
the available links is both assumed to be part of what we need to
have and implementable without too much trouble.

Push back by transit ASes is harder. This is what I mean by that:

      A --- B
    /         \
X             Y
    \         /
      C --- D

C's link to D may be low capacity or expensive, so D would prefer it
if X would send traffic to Y over another route if possible. C can
make this happen in BGP by prepending its AS one or more times so X
will see the following AS paths:

A B Y
C C C D Y

All else being equal, X will choose the path over A to reach Y.

The simple answer here is that if the multihomed site receives a BGP
feed just like today (except that it's a read only feed) and thus
makes outgoing path selection decisions just like today, transit ASes
have exactly the same tools as they have today. But presumably, if
shim6 takes off many smaller sites that aren't comfortable with BGP
will multihome also, so this push back won't work as well anymore.
Creating a new way to accomplish this result is probably possible,
but not entirely non-trivial, and probably something we wouldn't want
to deliver on day one.

Thoughts?

Another capability that would be hard to replicate with shim6 is
selective announcement. Today, many transit ASes allow multihomed
sites to influence the way their prefix is propagated to neighbors of
the transit AS. For instance, in the picture above X may decide that
the link between C and D is of low quality, and set a community on
the prefix it sends to C that tells C either that it should perform
AS path prepending on X's prefix ONLY towards D and not towards other
neighbors of C, or even not announce the prefix at all.

We would need considerable extra mechanisms to replicate this
capability, and maybe it can't even be fully replicated at all.

So how critical is this capability?

Delivery-date: Tue, 28 Feb 2006 19:07:21 +0000
Cc: shim6-wg <[email-masked]>, NANOG list <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG (forwarded note from John Payne)
Date: Tue, 28 Feb 2006 20:04:02 +0100
To: Todd Vierling <[email-masked]>

On 28-feb-2006, at 16:34, Todd Vierling wrote:

>> A B Y
>> C C C D Y

>> All else being equal, X will choose the path over A to reach Y.

> There's plenty of route mangler technologies out there that provide
> overriding BGP information to borders that trumps path length.   
> "All else"
> is often not as equal as you seem to expect.

> It's time to wake up and smell the intelligent routing trend.  The
> usefulness of prepending is rapidly dwindling.  Don't try to push  
> it as a
> future-compatible solution; it is not.  Prepending is not a tool;  
> it is a
> hack that has outlived its usefulness.

In my experience, if anything, AS path prepending is TOO effictive:  
just one prepend can make a 60/40 split that you're trying to get to  
50/50 into 25/75 instead. So I agree that it's not as useful as it  
used to be, but I blamed this on the flattening of the AS  
interconnection hierarchy. But maybe it's the routing/TE boxes that  
are responsible.

>> Another capability that would be hard to replicate with shim6 is  
>> selective
>> announcement.

> Now, selective announcement is something completely different --  
> but it's
> still a historical hack for lack of better mechanisms in BGP[34].   
> If the
> route isn't there at all, it won't be selected in today's world.

Right. That would be hard to accomplish with shim6.

> But also consider this:

> - C does not advertise the prefix for Y, but it does have the next
>   superprefix for Y (and C is "transit", so the superprefix must be
>   considered valid);

> - X's link to A dies.

> So X will still try to push packets over C to reach Y, and per the  
> existence
> of the superprefix on C, that route should[!] be valid.

This kind of thing is, as far as I can see, pretty much impossible to  
replicate in shim6. Mind you, even if we end up with PI in IPv6, it's  
unlikely that you get to do this with IPv6 because the address space  
and the provider aggregates are so large, that deagregating becomes a  
hazard rather than a nuisance. Deaggregating a /32 into /48 makes for  
upto 65536 additional routes, which is a third of the current IPv4  
routing table (and several dozen times the current IPv6 routing  
table). So I think most people will use strict prefix length filters  
to avoid this. At least, after it has happened for the first time.

> Don't think this will forever be a rare circumstance, either.  The  
> route
> mangling technologies I mentioned above are now starting to offer the
> ability for traffic to go out a "transit" neighbor so long as some
> containing prefix is advertised (even if it's not the most specific).

> Traffic engineering is happening on both ends of the BGP mesh  
> *today*, so
> you should present any proposed solution in that context.

I'm not too worried about what happens on both ends: since both ends  
implement the shim protocol and the two ends communicate with each  
other, we can build in whatever is required. The challenges are:

- getting site wide policies into the individual hosts or apply side  
wide policies in middleboxes in a secure way
- come up with a reasonable way to have information "in the middle"  
taken into account

And we have to figure out which capabilities must be present as a  
mandatory part of the specification on day one, and which can be  
optional and/or added later. (Ideally, all TE is kept outside of the  
base spec because modularity makes everything easier, but some stuff  
is only useful if it's everywhere so it either has to be mandatory or  
forget it, and other stuff is so important that we need it from day  
one.)

Delivery-date: Tue, 28 Feb 2006 17:10:50 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Fwd: I-D ACTION:draft-bagnulo-shim6-privacy-00.txt 
Date: Tue, 28 Feb 2006 18:09:50 +0100

Hi,

I have submitted the draft below for disucssion on the working group.

It is basically an analysis of the privacy of the shim6 protocol

Comments about the analysis itself and/or whether the identified issues 
are relevant and need to be addressed are very welcome

Thanks, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 27 de febrero de 2006 21:50:01 GMT+01:00
> Para: [email-masked]
> Cc: Asunto: I-D ACTION:draft-bagnulo-shim6-privacy-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Privacy Analysis for the SHIM6 protocol
> 	Author(s)	: M. Bagnulo
> 	Filename	: draft-bagnulo-shim6-privacy-00.txt
> 	Pages		: 9
> 	Date		: 2006-2-27
> 	
> This note presents a privacy analysis for the SHIM6 protocol for IPv6
> site multihoming support and the failure detection extensions for the
> SHIM6 protocol.This note does not attempt to provide a solution for
> providing SHIM6 protocol privacy.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-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-bagnulo-shim6-privacy-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-bagnulo-shim6-privacy-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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Tue, 28 Feb 2006 11:44:06 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Tue, 28 Feb 2006 12:43:44 +0100
To: Per Heldal <[email-masked]>

On 27-feb-2006, at 15:12, Per Heldal wrote:

> I share most of your views, but you are missing an important point:
> Frustration in the ops-community stems from inconsistency between
> operational policies and technical capabilities.

> Consider:

> * Current V4 multihomers (content providers in particular) are not
> willing to adopt V6 without a MH-solution.

> * RIRs currently don't support MH for v6 endsites.

> * shim6 is currently the only technical initiative to bring MH to  
> V6. It
> is therefore expected to bring any and all MH and TM-related
> functionality from day 1 (even far beyond just what's possible with
> BGP-tweaks).  That is about as realistic as expecting to find
> features related to stateful inspection of packet-streams in modern
> products (firewalls, load-balancers etc) explicitly described in the
> original TCP-specification.

Necessity is the mother of invention...

> In 5 or 10 years,

Any time someone mentions timelines like this that indicates to me an  
incomplete understanding of the problem. Everything we understand  
today can happen in less than 5 years.

> when supporting tools are in place for (near-)
> immediate renumbering or to add/remove prefixes to/from sites of *any*
> size including directory (DNS .. whatever) updates, and with tools to
> manage/coordinate traffic on any number of shim6-capable boxes  
> within a
> site this will no longer be an issue.

Unfortunately, it's becoming quite clear that IETF efforts to allow  
for rapid renumbering have dead ended. Renumbering itself is very  
easy and nearly 100% transparent to applications and the user in  
IPv6. Unfortunately, when hosts get different addresses some other  
stuff must change as well:

- ingress filtering/egress selection
- DNS records
- anything that has IP addresses hardcoded in general

And worse, all of this has to happen at pretty much the same time to  
be effective. In order to be able to do this, many things that are  
strict today must become more relaxed or the other way around, and  
operators simply don't seem to want it. (It would help if we could  
retire the whole filtering/firewalling security model that exists  
today.)

> In the meantime, if we want to give shim6 (or alternatives) time to
> evolve there are 2 options.

> - Openly and wholehartedly discourage v6 deployment for purposes where
> global reachability is expected till the technology is complete.

Looking at current IPv6 adoption it seems that discouragement isn't  
required.  :-)

>  . or .

> - Work with the RIRs, possibly with recommendations through IANA, to
> implement routing-policies for v6 which will work with existing
> technology.

Unfortunately the RIR constituency seems to be incapable of anything  
more productive than whine that they want PI in IPv6 just like it  
exists in IPv4.

If anyone is interested in exploring this seriously, which to me  
means finding new ways to aggregate that were summarily rejected in  
the past, I'm all for that.

Delivery-date: Tue, 28 Feb 2006 11:24:18 +0000
Date: Tue, 28 Feb 2006 05:11:41 -0600
From: Harold Grovesteen <[email-masked]>
To: Per Heldal <[email-masked]>
CC: shim6-wg <[email-masked]>, "Grovesteen, Harold" <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)

This is a multi-part message in MIME format.
--------------070205080306040302090502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Per Heldal wrote:

>On Mon, 27 Feb 2006 16:13:43 -0500 (EST), "Jason Schiller
>([email-masked])" <[email-masked]> said:
>[snip]
>  
>
>>I.m suggesting there must be some other way to provide current IPv4 style
>>TE capabilities for IPv6 without de-aggregating to the global Internet
>>routing table.  This can be in shim6 or 8+8 / GSE, or something else. 
>>But
>>supporting the full suite of TE capabilities is a day 1 requirement for
>>business customers, not just loading all links and failover.
>>    
>>
>
>That would mean no v6 for another 5 years or more. It isn't possible to
>implement something that doesn't exist. How do you sell that
>idea to the .gov crowd and others who are making serious plans for
>migration within the next 2-3 years?
>  
>
IPv6 is inevitable.  Sooner for this crowd to which my organization 
belongs than later for some others.  To believe that a full suite of TE 
capabilities is a day 1 requirement is an attempt to maintain business 
decisions based upon a technology that is outliving its usefulness.  Let 
those organizations and their supporters be lagards in adopting the new 
technology.  That too is a business decision.  Will IPv6 preclude some 
business decisions made with IPv4?  Certainly.  But will it allow others 
not possible?  Also certainly.  That is the nature of change.  Is shim6 
everthing I would like it to be?  No.  But, I lobbied hard in the multi6 
group for movement towards any site multihoming solution, because the 
real change with IPv6 is not the increased address space, but the change 
in the relationship between the ISP and its customers, a change to which 
both groups must ultimately adapt and movement towards a solution 
supporting that change was not happening.  Shim6 is progress in the 
right direction.  Become part of the solution not part of the problem.  
Can more TE capabilities be provided day one?  Maybe.  But it will not 
happen by demanding everything from the side lines and refusing to play 
until everyone gets their way.

Harold Grovesteen

--------------070205080306040302090502
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Per Heldal wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">On Mon, 27 Feb 2006 16:13:43 -0500 (EST), "Jason Schiller
(<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>)" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> said:
[snip]
  </pre>
  <blockquote type="cite">
    <pre wrap="">I.m suggesting there must be some other way to provide current IPv4 style
TE capabilities for IPv6 without de-aggregating to the global Internet
routing table.  This can be in shim6 or 8+8 / GSE, or something else. 
But
supporting the full suite of TE capabilities is a day 1 requirement for
business customers, not just loading all links and failover.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That would mean no v6 for another 5 years or more. It isn't possible to
implement something that doesn't exist. How do you sell that
idea to the .gov crowd and others who are making serious plans for
migration within the next 2-3 years?
  </pre>
</blockquote>
IPv6 is inevitable.&nbsp; Sooner for this crowd to which my organization
belongs than later for some others.&nbsp; To believe that a full suite of TE
capabilities is a day 1 requirement is an attempt to maintain business
decisions based upon a technology that is outliving its usefulness.&nbsp;
Let those organizations and their supporters be lagards in adopting the
new technology.&nbsp; That too is a business decision.&nbsp; Will IPv6 preclude
some business decisions made with IPv4?&nbsp; Certainly.&nbsp; But will it allow
others not possible?&nbsp; Also certainly.&nbsp; That is the nature of change.&nbsp;
Is shim6 everthing I would like it to be?&nbsp; No.&nbsp; But, I lobbied hard in
the multi6 group for movement towards any site multihoming solution,
because the real change with IPv6 is not the increased address space,
but the change in the relationship between the ISP and its customers, a
change to which both groups must ultimately adapt and movement towards
a solution supporting that change was not happening.&nbsp; Shim6 is progress
in the right direction.&nbsp; Become part of the solution not part of the
problem.&nbsp; Can more TE capabilities be provided day one?&nbsp; Maybe.&nbsp; But it
will not happen by demanding everything from the side lines and
refusing to play until everyone gets their way.<br>
<br>
Harold Grovesteen<br>
</body>
</html>

--------------070205080306040302090502--

Delivery-date: Tue, 28 Feb 2006 03:16:25 +0000
From: "Per Heldal" <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>, "shim6-wg" <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Tue, 28 Feb 2006 04:15:09 +0100

On Mon, 27 Feb 2006 16:13:43 -0500 (EST), "Jason Schiller
([email-masked])" <[email-masked]> said:
[snip]
> I.m suggesting there must be some other way to provide current IPv4 style
> TE capabilities for IPv6 without de-aggregating to the global Internet
> routing table.  This can be in shim6 or 8+8 / GSE, or something else. 
> But
> supporting the full suite of TE capabilities is a day 1 requirement for
> business customers, not just loading all links and failover.

That would mean no v6 for another 5 years or more. It isn't possible to
implement something that doesn't exist. How do you sell that
idea to the .gov crowd and others who are making serious plans for
migration within the next 2-3 years?

An alternative could be "controlled fragmentation" through temporary PI
assignments to be re-evaluated periodically and to be revoked once the
technology is ready. Renumbering of end-sites should be a non-issue once
all the supporting software and hardware gadgets are in place. [This is
probably an issue for the RIR-communities + IANA to work out.] 

Personally I see this primarily as an alternative if v6 routing isn't
solved before we run out of v4 addresses. It doesn't make that much
sense to implement v6 as a sort of "v4+".

> 
> Is it the consensus of the shim6 working group that the full suite of TE
> capabilities should not be a requirement?  Or is this just the opinion of
> a few vocal people?
> 

Don't researchers picture a slightly more modular approach? The basics
of shim6 must have "hooks" for TE, but it is a long way from there to
complete TE implementation that support everyone's needs (a:client
b:server c:stub-network d:transit-network). Much of this should probably
become separate standards in the long term (e.g. mechanisms to exchange
locator-selection-data between shim6 hosts in a network). If not, the
basics of shim6 may become way too complex.

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

Delivery-date: Tue, 28 Feb 2006 00:15:22 +0000
Date: Mon, 27 Feb 2006 16:15:31 -0800
From: Tony Li <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)

Jason,

> As Ted Seely from Sprint said, .Isn.t new technology supposed to be better
> than the technology it replaced?. 

'Better' is certainly open to interpretation and may be evaluated by
differing parties according to different metrics, thus leading to
different results.  One might recall that even since the introduction of
the CD, there is still a steadfast group of audiophiles who feel that
the sound of vinyl is 'better'.

> Is it the consensus of the shim6 working group that the full suite of TE
> capabilities should not be a requirement?  Or is this just the opinion of
> a few vocal people?

I can't speak to the consensus, but so far the requests for TE
capabilities seem to be isomorphic to a request for a return to the v4
routing architecture, complete with PI addressing and global prefix
advertisement.

While I have no objection to providing any TE functionalities as part of
our multihoming solution, I think that we also need to remember that our
solution also needs to satisfy other constraints: namely that we have
tried a PI-based solution before and that we are trying very hard to
avoid that segment of the solution space again due to the cost
implications for the routing subsystem.  We are also operating within
some (possibly undue) constraints imposed by the existing v6
architecture.  Given these constraints, if we add in a requirement to
replicate all of the functionality that we have with v4 TE, we may well
find that the solution space is void.

Thus, I feel that we have to prioritize our constraints.  To me,
creating a scalable routing subsystem is paramount, as without that, we
effectively have no network.  Second, due to the realities of the day,
we need to respect the portions of the v6 architecture that cannot be
changed, at least within this WG.  And lastly, we can provide any
feature functionality that is compatible with the above constraints.

Regards,
Tony

Delivery-date: Mon, 27 Feb 2006 21:22:23 +0000
Date: Mon, 27 Feb 2006 16:13:43 -0500 (EST)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
To: shim6-wg <[email-masked]>

Maybe I am putting the cart before the horse.  I do admit that the shim6
protocol needs to be flushed out first.  My concern is that the horse is
capable of easily being hitched up to the cart.  We should not be
designing a protocol without keeping all of the TE possibilities in
mind.  We need to have a rough idea of how we plan to provide for each of
the current TE profiles so that any needed hooks can be added to the
protocol.  

The BGP based inter-AS TE scenarios I describe are currently being used by
business customers in the Internet today.  Without these or similar
functionalities, these business customers will consider IPv6 .not ready
for prime time. and will be unlikely to adopt IPv6 for revue generating or
mission critical traffic.  In short, without full support for TE, IPv6 is
not ready for business traffic.

When these customers are forced to IPv6 they will be unhappy about the
lack of support for their TE profile.

As Ted Seely from Sprint said, .Isn.t new technology supposed to be better
than the technology it replaced?.  In other words, why will people want to
migrate to a new technology that has less functionality?

The other possibility is what I am seeing now.  Operators are suggesting
that as there is no good way to provide for the current IPv4 TE
capabilities in IPv6, that we should simply de-aggrgegate into the global
routing table.  While this may not present a problem in the next year or
two, this may lead us to a place we don.t want to be at in the long term. 

I.m suggesting there must be some other way to provide current IPv4 style
TE capabilities for IPv6 without de-aggregating to the global Internet
routing table.  This can be in shim6 or 8+8 / GSE, or something else.  But
supporting the full suite of TE capabilities is a day 1 requirement for
business customers, not just loading all links and failover.

Is it the consensus of the shim6 working group that the full suite of TE
capabilities should not be a requirement?  Or is this just the opinion of
a few vocal people?

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

Delivery-date: Mon, 27 Feb 2006 19:50:04 +0000
Date: Mon, 27 Feb 2006 11:48:40 -0800
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Tony Li <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

Iljitsch van Beijnum wrote:

> There are two problems with allowing routers to rewrite source addresses:
> 
> 1. The routers must know which packets are "legacy" and can't have their 
> source address changed vs which packets are controlled by shim6 or 
> another mechanism that can handle rewritten source addresses.
> 
> 2. In current shim6, only previously negotiated source addresses may be 
> used, which means the shim6-enabled hosts in a site and the rewriting 
> routers must coordinate their efforts so correspondent hosts don't see 
> unexpected source addresses.

FWIW draft-nordmark-shim6-esd-00.txt is on the way to the I-D directory, 
and it has some ideas for how to address this.

> The first issue is readily solvable by simply having shim6 hosts put a 
> magic value in the upper 64 bits of the source address that indicates 
> "rewriting permitted".

Or next hdr = IPPROTO_SHIM6.

> The second issue is a bit more complex but not fatally so, IMO.
> 
> So if we want to, we can explore source address rewriting.
> 
> The reason we haven't done so (or, at least, the reason I haven't pushed 
> this) is that it doesn't solve anything in the short term because we 
> can't depend on this capability in the forseeable future, so shim6 must 
> also work without the rewriting capability present.

Agreed.  Getting a basic locator agility mechanism which works without 
assuming router rewriting has been the most important thing so far.

   Erik

Delivery-date: Mon, 27 Feb 2006 18:51:24 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Mon, 27 Feb 2006 19:50:35 +0100
To: Erik Nordmark <[email-masked]>

On 27-feb-2006, at 16:22, Erik Nordmark wrote:

>>> 2) The first hit is of critical importance to content providers  
>>> (many
>>> of whom couldn't legitimately justify a /32).  Hunting through  
>>> DNS to
>>> find a locator that works won't fly.

>> Right. So how do we solve this? Second shim? Shim-before-syn?

> It is very hard *under* the current socket API, since the connect()  
> and sendto() calls do not know that there is alternative addresses  
> to try.

> But if the application is using some middleware that has the  
> equivalent of a connect_to_name(), then it isn't hard to implement  
> that API on top of the socket API by using non-blocking connect()  
> and trying different addresses relatively quickly (instead of  
> waiting for a minute or so until TCP times out, it could try a  
> second connect on a different socket after a few seconds).

True enough, and I certainly hope that frameworks, libraries and the  
like that implement a connect-by-name type call do this. However,  
this isn't the only way to solve this. One very interesting feature  
that I discovered this summer when finally upgrading to a more recent  
version of FreeBSD was the address selection policy mechanism (see  
the ip6addrctl command, Windows also has it as netsh interface ipv6  
show/set prefixpolicy). With this, it's possible to control address  
preferences system-wide. I'm not sure how it's implemented exactly,  
but apparently this policy is applied somewhere between the DNS  
resolver and the application.

One way to put this mechanism to good use is when a DNS lookup for an  
AAAA record returns more than one address, is to go out and check  
which address is alive and/or apply local, remote and in-the-middle  
traffic engineering policies. Since the application hasn't committed  
to any particular address choice yet, this should work very well. The  
only downside is that all of this will take an extra roundtrip.

I imagine that we can send out some kind of quick reachability  
check / information request to the other side, maybe even towards all  
the addresses returned by the DNS. I have to read up on the R1/R2  
stuff, but I imagine this could be an R1, without necessarily  
completing the full handshake at this time.

Since we're waiting for information to come back from the  
correspondent anyway, we can use this time to query a policy server  
that's local to the site or is located at one or more of the site's  
ISPs. If the servers don't waste time, the answer for this should be  
back by the time the correspondent answers anyway.

Another advantage of checking reachability at this stage is that we  
can easily avoid ingress filtering: simply try the reachability check  
towards the correspondent with the cartesian product of all local and  
remote addresses at the same time. The probes with an ingress  
filtered source address shouldn't even take up any non-local  
bandwidth if the egress routers also perform this filtering.

Delivery-date: Mon, 27 Feb 2006 15:24:31 +0000
Date: Mon, 27 Feb 2006 07:22:49 -0800
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)

Iljitsch van Beijnum wrote:

>> 2) The first hit is of critical importance to content providers (many
>> of whom couldn't legitimately justify a /32).  Hunting through DNS to
>> find a locator that works won't fly.
> 
> Right. So how do we solve this? Second shim? Shim-before-syn?

It is very hard *under* the current socket API, since the connect() and 
sendto() calls do not know that there is alternative addresses to try.

But if the application is using some middleware that has the equivalent 
of a connect_to_name(), then it isn't hard to implement that API on top 
of the socket API by using non-blocking connect() and trying different 
addresses relatively quickly (instead of waiting for a minute or so 
until TCP times out, it could try a second connect on a different socket 
after a few seconds).

    Erik

Delivery-date: Mon, 27 Feb 2006 14:12:41 +0000
From: "Per Heldal" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: [email-masked]
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Mon, 27 Feb 2006 15:12:00 +0100

On Fri, 24 Feb 2006 12:08:42 +0100, "Iljitsch van Beijnum"
<[email-masked]> said:
> On 26-okt-2005, at 18:08, Geoff Huston wrote:
> 
> > Public thanks to Dave, Geoff, Vijay, Ted and Jason for their
> > involvement in bringing shim6 to the NANOG conference.
> 
> I just looked at the stream and I can't say that this made me vary  
> happy. </understatement>
> 
> Some of the comments made were nothing short of ridiculous, with  
> people claiming authority over the traffic engineering decisions made  
> by their _customers_. Understanding of what shim6 is and what it does  
> was sorely lacking.

I share most of your views, but you are missing an important point:
Frustration in the ops-community stems from inconsistency between
operational policies and technical capabilities.

Consider:

* Current V4 multihomers (content providers in particular) are not
willing to adopt V6 without a MH-solution.

* RIRs currently don't support MH for v6 endsites. 

* shim6 is currently the only technical initiative to bring MH to V6. It
is therefore expected to bring any and all MH and TM-related
functionality from day 1 (even far beyond just what's possible with
BGP-tweaks).  That is about as realistic as expecting to find
features related to stateful inspection of packet-streams in modern
products (firewalls, load-balancers etc) explicitly described in the
original TCP-specification.

In 5 or 10 years, when supporting tools are in place for (near-)
immediate renumbering or to add/remove prefixes to/from sites of *any*
size including directory (DNS .. whatever) updates, and with tools to
manage/coordinate traffic on any number of shim6-capable boxes within a
site this will no longer be an issue. 

In the meantime, if we want to give shim6 (or alternatives) time to
evolve there are 2 options.

- Openly and wholehartedly discourage v6 deployment for purposes where
global reachability is expected till the technology is complete.

 . or .

- Work with the RIRs, possibly with recommendations through IANA, to
implement routing-policies for v6 which will work with existing
technology.

//per

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

Delivery-date: Mon, 27 Feb 2006 12:42:03 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Mon, 27 Feb 2006 13:41:13 +0100
To: Jason Schiller ([email-masked]) <[email-masked]>

Jason,

On 27-feb-2006, at 8:02, Jason Schiller ([email-masked]) wrote:

> As far as TE relates to IPv6, I have concerns that the TE  
> requirements are
> not fully defined.  Based on past discussions in the working group,  
> and
> after reading some IPv6 publications that discuss how BGP based TE is
> used, it appears people think the only valid TE concerns are 1. How to
> load up all links, and 2. How to make failover work. In reality  
> there are
> more requirements!

"Requirement" is a very big word. We should be careful not to use it  
unless the issue under discussion is absolutely essential for the  
solution under consideration. In my opinion, many of the examples you  
provide don't qualify. In essence, you're saying a new IPv6 mechanism  
should provide any and all capabilities that exist today. And  
obviously the application people say the same thing, as do the  
transport people and, not in the least, the security people. Since  
all these sets of requirements can't be fulfilled at the same time,  
that means either we throw up our hands and go home, or we downgrade  
some requirements to "good to have, but not essential" and come to  
terms with having to give up some stuff that we'd really like to  
have. Obviously what's left has to be worthwhile.

> All in all it doesn't matter why people want a backup link or how  
> it is
> useful.  The only thing that matters is that people desire this
> functionality.

Again, I disagree. The trouble today is that pretty much everything  
that CAN be done IS done. Upgrading everything that's possible today  
to the level of requirement makes the problem impossible to solve.  
And in many cases, there are different ways to meet the underlying  
need other than just deliver the same mechanisms that exist today.  
Basically, we're trying to invent screws in a world that only knows  
nails. Show people a screw driver and they're going to say that it's  
way too light and the wrong shape to be useful. Show them a screw,  
and they'll object that you can't possibly hammer that in.

> In addition, the IPv6 multihoming solution should not remove the  
> current
> tools transit ASes currently have in IPv4 style multihoming.  This  
> doesn't
> mean transit ASes simply over-ride the down stream TE preferences.  A
> transit AS attempts to move the packet closer to the destination.   
> If the
> destination is more than one AS away, then it may be reached through
> multiple neighbor ASes.  In this case the transit AS may have some TE
> choices.

Could you provide some examples of mechanisms that you consider  
important in day-to-day traffic management?

>> Now obviously most ISPs are multihomed themselves so they want to do
>> their own TE. That's completely legitimate. However, that doesn't  
>> mean
>> that they get to decide how their customers can do TE.

> It is not only important for transit ASes to be able to traffic  
> engineer
> their traffic to and from other ASes as I have described  
> previously.  This
> can also be used to accommodate both the source outbound TE and the
> destination inbound TE when they conflict.

> For example say cust1 and cust2 are both multihomed to Sprint and
> UUNET.  Say the cust1 wants to use UUNET as the primary inbound and
> outbound link because it is higher performance.  Say cust2 wants to  
> use
> the Sprint link as the primary inbound and outbound link due to cost
> savings.  In this case cust1 can have a default route to UUNET and  
> a high
> cost default route to Sprint.  Cust1 can advertise their network to  
> UUNET
> with the default local preference.  Cust1 can advertise their  
> network to
> Sprint with a community to lower the local preference.  Cust2 will  
> do the
> opposite.  Cust2 will have a default route to Sprint and a high cost
> default route to UUNET.  Cust2 will advertise their network to  
> Sprint with
> the default local preference.  Cust2 will advertise their network  
> to UUNET
> with a community to lower the local preference.

Ok.

> In this case traffic from cust1 will get forwarded to UUNET due to the
> more preferred default route.  UUNET will honor the community from  
> cust2
> to lower the local preference on the route it learns directly from
> cust2.  Traffic will be forwarded to Sprint who will pass it along to
> Cust2.

Right.

> The opposite will happen in the reverse direction.  Cust2 will  
> forward the
> traffic to Sprint.  Sprint will honor the community from cust1 to  
> lower
> the local preference on the route it learns directly from cust1.   
> Traffic
> will be forwarded to UUNET who will pass it along to Cust1.

Sure.

> Both cust1 and cust2 inbound and outbound TE policies can be  
> honored even
> if they conflict with each other.

But what's the problem here? The same thing can easily be  
accomplished by cust1 advertising adresses they got from UUNET and  
also set a higher priority default route to UUNET while cust2 does  
the same with Sprint. The only difference is that in this case, when  
cust2 sets up a session towards cust1, it can ignore the higher  
priority UUNET address and connect to the lower priority Sprint  
address instead. But I don't see any reason for them to do so.

>> I think what we have here is a disconnect between what's going on in
>> the wg (and the multi6 design teams) and what's visible from the
>> outside.

> Maybe there is a disconnect.  Maybe my concerns have been addressed by
> private off-list communications.  If that is the case, can someone  
> address
> the concern that the current "IPv4 style" TE functionality is  
> needed for
> IPv6 multihoming?  Can someone define what they think are the TE
> requirements (as far as I can tell they are lacking)? Can someone  
> explain
> how each of the current "IPv4 style" functionalities will be  
> supported in
> shim6?

It's not that concrete. But we're certainly not ignoring TE.

> Maybe someone can come to the next NANOG and set things straight
> on a pannel?

Maybe the next time the NANOG meeting is held in a place where  
asbestos is still legal?  :-)

> It is my understanding that DNS may be an incomplete list of  
> locators, or
> may have multiple sets of locators for multiple round robin hosts.   
> Shim6
> will exchange the complete locator set for a single host.  I assume  
> if you
> want TE to work, then in addition to exchanging locators, you will  
> need to
> exchange inbound TE preferences.  This also means you may want to
> immediately switch over to use the shim so that you TE works prior  
> to a
> failure.

We'll have to see how that plays out in practice. Personally, I  
wouldn't be too happy about that because it makes everything much  
less transparent and if we get a shim header in all shimmed packets  
this uses up bandwidth unnecessarily.

>> Right. So there is precedent for storing state for 30000 instances of
>> "something". Servers are getting a lot faster and memory is getting
>> cheaper so adding a modest amount of extra state for longer lived
>> associations shouldn't be problematic.

> The impression I get from content providers is that it is non- 
> trivial to
> support the added state from shim6.

I would be interested to learn how they know this.

> Yes, computers are getting faster,
> and memory cheaper, but these systems may negatively impact their  
> business
> models as power consumption, cooling requirements, and rack space
> consumption increase.  But I won.t try to speak authoritative on this
> issue, and will instead defer to some of the larger content providers.

I don't think this will be an issue at all. Let's see how things look  
when the protocols start to take their final shape.

>> Let me speak for myself and speculate a bit: what we should do is
>> have multihomed sites publish SRV (or versy similar) records with two
>> values: a "strong" value that allows primary/backup mechanisms, and a
>> "weak" value that allows things like 60% of all sessions should go to
>> this address and 40% to that one.

>> Then, before a host sets up a session it consults a local policy
>> server that adds local preferences to the remote ones and also
>> supplies the appropriate source address that goes with each
>> destination address. New mechanisms to distribute this information
>> have been proposed in the past, but there is already a service that
>> is consulted before the start of most sessions, so it makes sense to
>> reuse that service. (No prizes for guessing what service I'm getting
>> at.)

> I think using SRV records for TE is overloading the DNS function.

I know some people object against that, but I find it hard to take  
such objections seriously. As long as the information can be cached  
like other DNS info there should be no impact at all on DNS operation.

> However I do have some concerns about TE preferences in DNS.   
> First, DNS
> records tend to be cached for scalability, and to reduce traffic.  TE
> policy may need to change quickly to reflect a topology change.  This
> seems problematic.

The way I see it, the information in the DNS should remain mostly  
stable regardless of outages and the like.

> Secondly, I am concerned that DNS may only allow for the end point to
> indicate their inbound preferences, but what about the cumulative TE
> preferences of all of the ASes in each of the different paths  
> between the
> source and destination,  how is this reflected in DNS based TE?

If we implement this as I outlined above, an ISP could run a TE aware  
DNS server that has a BGP feed to import traditional BGP TE info.

     A ----- C
   / |       | \
X   |       |  Y
   \ |       | /
     B ----- D

So suppose X wants to set up a session towards Y. Suppose that Y's  
preference is 40% of its traffic through C and 60% through D. If X  
then asks the DNS server at A for Y's addresses and SRV info, A will  
return Y(C) and Y(D) along with the 40/60 info, as published by Y.  
But A will also add the information that Y(C) is reachable over 2  
hops while Y(D) is 3 hops. I'm not sure yet how exactly we can  
integrate this information, but X could divide 40 by 2 = 20 and 60 by  
3 = 20 and then toss a virtual coin.

If X also queries B the info here would be 40 / 3 = 13 and 60 / 2 = 30.

Since the TE info added by the DNS servers would probably be at /32  
resolution, it could change often even though the regular published  
DNS info could be fairly static. The only way this wouldn't work so  
well is when a host starts the mother of all file transfers and then  
something happens that requires a TE intervention. The file transfer  
would continue without receiving any new TE input.

> All the ASes that are advertising 55,000 more specifics to the global
> Internet routing table will care when you take this TE tool away  
> from them
> and the traffic loading on their links change.

We're not taking anything away... IPv4 can continue without changes  
until either it blows up or it has outlived its usefulness.

>> Unfortunately this is incompatible with hop-by-hop forwarding for
>> outgoing traffic from the customer. Obviously this can be solved both
>> today and with shim6 using MPLS or similar.

> Inter-domain MPLS with customers or Peers is not a tool most large
> networks are comfortable with.  This needs to be solved inside of  
> shim6.

I think asking shim6 to support non hop-by-hop policies is too much  
to ask. You can't do this today either.

Delivery-date: Mon, 27 Feb 2006 07:04:19 +0000
Date: Mon, 27 Feb 2006 02:02:33 -0500 (EST)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6-wg <[email-masked]>

Iljitsch,

As far as TE relates to IPv6, I have concerns that the TE requirements are
not fully defined.  Based on past discussions in the working group, and
after reading some IPv6 publications that discuss how BGP based TE is
used, it appears people think the only valid TE concerns are 1. How to
load up all links, and 2. How to make failover work. In reality there are
more requirements!

On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

> If you have several links to the internet, you don't want one to sit
> idle while another is congested. So traffic engineering is an
> essential part of multihoming.

> What I said was that I didn't understand why people want to have two  
> links and then have the second one sit idle until the first fails. I  
> know people want this because I used to configure this for customers  
> when I worked at UUNET NL. But my thinking is that if you have  
> multiple links, you'll want to use all of them.

The fact of the matter is that there are various other desired
configurations, including various combinations of primary / backup, best,
load sharing across links, and the ability to dial traffic up or down in
all scenarios.  

We can debate about the various merits of why someone would want a backup
link that is idle.  The backup link may cost less, for example we offer a
cheaper priced shadow link in addition to a primary link, or the primary
link may be with one ISP at fixed price, and the backup may be a metered
service with another IPS.  The backup link may have lower quality such as
an over subscribed network, some packet loss, or may be a high latency
satellite link.  The primary link may be an OC-3 and the backup link may
be three DS-3s.  

All in all it doesn't matter why people want a backup link or how it is
useful.  The only thing that matters is that people desire this
functionality.

In addition, the IPv6 multihoming solution should not remove the current
tools transit ASes currently have in IPv4 style multihoming.  This doesn't
mean transit ASes simply over-ride the down stream TE preferences.  A
transit AS attempts to move the packet closer to the destination.  If the
destination is more than one AS away, then it may be reached through
multiple neighbor ASes.  In this case the transit AS may have some TE
choices. 

On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

> Now obviously most ISPs are multihomed themselves so they want to do
> their own TE. That's completely legitimate. However, that doesn't mean
> that they get to decide how their customers can do TE.

It is not only important for transit ASes to be able to traffic engineer
their traffic to and from other ASes as I have described previously.  This
can also be used to accommodate both the source outbound TE and the
destination inbound TE when they conflict.  

For example say cust1 and cust2 are both multihomed to Sprint and
UUNET.  Say the cust1 wants to use UUNET as the primary inbound and
outbound link because it is higher performance.  Say cust2 wants to use
the Sprint link as the primary inbound and outbound link due to cost
savings.  In this case cust1 can have a default route to UUNET and a high
cost default route to Sprint.  Cust1 can advertise their network to UUNET
with the default local preference.  Cust1 can advertise their network to
Sprint with a community to lower the local preference.  Cust2 will do the
opposite.  Cust2 will have a default route to Sprint and a high cost
default route to UUNET.  Cust2 will advertise their network to Sprint with
the default local preference.  Cust2 will advertise their network to UUNET
with a community to lower the local preference.

In this case traffic from cust1 will get forwarded to UUNET due to the
more preferred default route.  UUNET will honor the community from cust2
to lower the local preference on the route it learns directly from
cust2.  Traffic will be forwarded to Sprint who will pass it along to
Cust2.  

The opposite will happen in the reverse direction.  Cust2 will forward the
traffic to Sprint.  Sprint will honor the community from cust1 to lower
the local preference on the route it learns directly from cust1.  Traffic
will be forwarded to UUNET who will pass it along to Cust1. 

Both cust1 and cust2 inbound and outbound TE policies can be honored even
if they conflict with each other. 

On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

>
> On 24-feb-2006, at 19:47, Jason Schiller ([email-masked]) wrote:
>
> > I am baffled by the fact that Service Provider Operators have come  
> > out in
> > this forum, at the IAB IPv6 multihoming BOF, and other places, and  
> > have
> > explained how they and their customers use traffic engineering, yet up
> > until now, shim6 has not tried to provide thier needed functionality.
>
> I think what we have here is a disconnect between what's going on in  
> the wg (and the multi6 design teams) and what's visible from the  
> outside.
>
> I remember MANY conversations, in email and during meetings, about  
> traffic engineering. And for me, there has never been any question  
> that traffic engineering is a must-have for any multihoming solution.  
> Paying for two (or more) links and only being able to use one 99% of  
> the time is simply too cost-ineffective. And just maybe we can  
> convince people that shim6 makes for good multihoming even though it  
> doesn't give you portable address space, but it's never going to fly  
> if the TE is unequivocally worse than what we have today. (And I've  
> said this in the past.)
>
> However, for a number of reasons this isn't all that apparent to an  
> outside observer:
>
> - part these conversations were on closed design team lists, private  
> email or in (design team/interim) meetings (for instance, only 3% of  
> the messages in multi6 for the last couple of years mention TE)
> - I don't think any of us, but at least not me, saw TE as a  
> particularly hard-to-solve problem
> - TE can only happen if the base mechanisms are well understood, so  
> were focussing on those first

Maybe there is a disconnect.  Maybe my concerns have been addressed by
private off-list communications.  If that is the case, can someone address
the concern that the current "IPv4 style" TE functionality is needed for
IPv6 multihoming?  Can someone define what they think are the TE
requirements (as far as I can tell they are lacking)? Can someone explain
how each of the current "IPv4 style" functionalities will be supported in
shim6?  

Maybe someone can come to the next NANOG and set things straight 
on a pannel?

> > -First hit is critical
> >   * establishing shim6 after the session starts doesn't help
> >     short lived sessions
>
> I'm not sure where this comes from. Since shim6 doesn't come into  
> play until there is a failure, and failures are too rare to be  
> meaningful in TE, the shim6 failover protocol itself is fairly  
> meaningless for TE. What we need is mechanisms to do source/ 
> destination address selection in a way that can be traffic  
> engineered. Length of individual sessions is meaningless as shim6  
> doesn't work per-session. Most short sessions are part of a longer  
> lived interaction (i.e., a user visiting a WWW server and retrieving  
> dozens or hundreds of resources over the course of a dozen seconds to  
> many minutes).

It is my understanding that DNS may be an incomplete list of locators, or
may have multiple sets of locators for multiple round robin hosts.  Shim6
will exchange the complete locator set for a single host.  I assume if you
want TE to work, then in addition to exchanging locators, you will need to
exchange inbound TE preferences.  This also means you may want to
immediately switch over to use the shim so that you TE works prior to a
failure.

> >   * Keeping shim6 state on the end host doesn't scale for content
> >     providers.  A single server may have 30,000 concurrent TCP  
> > sessions
>
> Right. So there is precedent for storing state for 30000 instances of  
> "something". Servers are getting a lot faster and memory is getting  
> cheaper so adding a modest amount of extra state for longer lived  
> associations shouldn't be problematic.

The impression I get from content providers is that it is non-trivial to
support the added state from shim6.  Yes, computers are getting faster,
and memory cheaper, but these systems may negatively impact their business
models as power consumption, cooling requirements, and rack space
consumption increase.  But I won.t try to speak authoritative on this
issue, and will instead defer to some of the larger content providers.

> Let me speak for myself and speculate a bit: what we should do is  
> have multihomed sites publish SRV (or versy similar) records with two  
> values: a "strong" value that allows primary/backup mechanisms, and a  
> "weak" value that allows things like 60% of all sessions should go to  
> this address and 40% to that one.
>
> Then, before a host sets up a session it consults a local policy  
> server that adds local preferences to the remote ones and also  
> supplies the appropriate source address that goes with each  
> destination address. New mechanisms to distribute this information  
> have been proposed in the past, but there is already a service that  
> is consulted before the start of most sessions, so it makes sense to  
> reuse that service. (No prizes for guessing what service I'm getting  
> at.)

I think using SRV records for TE is overloading the DNS function.  Again,
I.m not a DNS server operator, and cannot speak authoritatively on this,
and will defer to them.  

However I do have some concerns about TE preferences in DNS.  First, DNS
records tend to be cached for scalability, and to reduce traffic.  TE
policy may need to change quickly to reflect a topology change.  This
seems problematic.

Secondly, I am concerned that DNS may only allow for the end point to
indicate their inbound preferences, but what about the cumulative TE
preferences of all of the ASes in each of the different paths between the
source and destination,  how is this reflected in DNS based TE?

>
> This would allow for pretty fine tuned incoming TE, as long as the  
> other end doesn't have a reason to override the receiving site's  
>preferences.

Current "IPv4 style" TE can allow for conflicting source outbound policy
and destination inbound policy as long as an AS lies between them.

> > |Yuck, you should never announce more specifics for this.
>
> > Please beleive the DFZ Service Provider's when the explain how  
> > they, and
> > their customers do TE.
>
> I believe that they do it, because I see that the global routing  
> table has increased by 16% last year. I have to admit that I've done  
> this myself from time to time, but only if AS path prepending (or  
> changing the origin attribute) wouldn't result in something  
> reasonable. It seems to me that for many people deaggregating is the  
> default these days. And then not just breaking a /20 into two /21s,  
> but go for broke and announce 16 /24s, who cares?

All the ASes that are advertising 55,000 more specifics to the global
Internet routing table will care when you take this TE tool away from them
and the traffic loading on their links change.

> > Transit AS TE is more critical in the case of moderate sized transit AS
> > that is purchasing transit from multiple upstreams.  Especally when links
> > are cost prohibative.  Take a large South American ISP that has 16 STM-1s,
> > where 4xSTM1 use the Americas 2 oceananic cable system to up stream
> > transit provider1, 4xSTM1 use the Emergia oceananic cable system to up
> > stream transit provider1, 4xSTM1 use the Americas 2 oceananic cable system
> > to up stream stream transit provider2, and 4xSTM1 use the Americas 2
> > oceananic cable system to up stream stream transit provider2.  Now imagine
> > that your most important customer who always complains about latency
> > should always use the Americas 2 oceananic cable system to up stream
> > tranist provider1.  Also imagine all other traffic should load all the
> > other links as equally as possible.  and given that any one or more links
> > fail, all the links should be loaded as equally as possible.  Note: This
> > is just one example of a real world customer.
> Unfortunately this is incompatible with hop-by-hop forwarding for  
> outgoing traffic from the customer. Obviously this can be solved both  
> today and with shim6 using MPLS or similar.

Inter-domain MPLS with customers or Peers is not a tool most large
networks are comfortable with.  This needs to be solved inside of shim6.

___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 Sat, 25 Feb 2006, Mikael Abrahamsson wrote:

> Date: Sat, 25 Feb 2006 10:11:49 +0100 (CET)
> From: Mikael Abrahamsson <[email-masked]>
> To: shim6-wg <[email-masked]>
> Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
> 
> On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:
> 
> > What I said was that I didn't understand why people want to have two links 
> > and then have the second one sit idle until the first fails. I know people 
> > want this because I used to configure this for customers when I worked at 
> > UUNET NL. But my thinking is that if you have multiple links, you'll want to 
> > use all of them.
> 
> Real backup is 1:1. If you buy 50+50 megs and use 60 (30+30), if one fails 
> you do not have full backup.
> 
> I can see your case, we have customers with 100 meg connections and 2M 
> backup, with the reasoning that 2M is better than nothing and they do not 
> want to pay 100+100. They're only interested in backupping a subset of 
> their traffic so they ACL the backup to only allow certain traffic in the 
> case of a failure on the primary high-bw link.
> 
> Also, we charge less for the backup if it's not used normally, but that's 
> for two connections into the same ISP, not multihoming between two ISPs.
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> 

Delivery-date: Sun, 26 Feb 2006 16:43:52 +0000
Cc: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: [Fwd: Review comments on draft-ietf-shim6-proto-03.txt]
Date: Sun, 26 Feb 2006 17:42:45 +0100
To: Erik Nordmark <[email-masked]>

On 16 feb 2006, at 19.28, Erik Nordmark wrote:

>
> Geoff has sent me many very good editorial clarifications which  
> I've applied to the draft.
>
> But there was one where I didn't quite agree that it was an  
> editorial change so it makes sense to discuss it on the list.
>
> The text and Geoff's suggested change were:
>
> 1.2  Non-Goals
>
>    The assumption is that the problem we are trying to solve is site
>    multihoming, with the ability to have the set of site locator
>    prefixes change over time due to site renumbering.  Further, we
>    assume that such changes to the set of locator prefixes can be
>    relatively slow and managed; slow enough to allow updates to the  
> DNS
>    to propagate.  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.   
> However, it
> |   might turn out that the shim6 protocol can be a useful component,
> |   e.g., for route optimization in the context of host mobility.
>
> replace with
> -------
>
> be applicable to host mobility, although this is an area for  
> further study.
>
>
> ---
>
> While the shim6 WG hasn't been chartered to solve the mobility  
> problem, the above text in the draft states (and I think accurately  
> so) that shim6 can be useful for route optimization when shim6 is  
> coupled with host mobility.
>
> Thus shim6 has some potential applicability to mobility.
>
> Hence I think Geoff's suggestion is making a too strong statement,  
> even if we do not today have consensus around how mobility 
> +multihoming will evolve.
>
> Comments?

<any hats off>

I do make the observation that our charter says :

o Compatibility will remain for existing mobility mechanisms. It will
be possible to use Mobile IPv6 on a node that also supports Shim6.
However, any optimizations or advanced configurations are out of
scope for shim6.

So I am kind of inclined to agree with Geoff :-)

Although I can't say I feel strongly either...

- kurtis -

Delivery-date: Sat, 25 Feb 2006 09:13:10 +0000
Date: Sat, 25 Feb 2006 10:11:49 +0100 (CET)
From: Mikael Abrahamsson <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Organization: People's Front Against WWW

On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

> What I said was that I didn't understand why people want to have two links 
> and then have the second one sit idle until the first fails. I know people 
> want this because I used to configure this for customers when I worked at 
> UUNET NL. But my thinking is that if you have multiple links, you'll want to 
> use all of them.

Real backup is 1:1. If you buy 50+50 megs and use 60 (30+30), if one fails 
you do not have full backup.

I can see your case, we have customers with 100 meg connections and 2M 
backup, with the reasoning that 2M is better than nothing and they do not 
want to pay 100+100. They're only interested in backupping a subset of 
their traffic so they ACL the backup to only allow certain traffic in the 
case of a failure on the primary high-bw link.

Also, we charge less for the backup if it's not used normally, but that's 
for two connections into the same ISP, not multihoming between two ISPs.

-- 
Mikael Abrahamsson    email: [email-masked]

Delivery-date: Fri, 24 Feb 2006 22:36:49 +0000
Cc: Mikael Abrahamsson <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Fri, 24 Feb 2006 23:35:53 +0100
To: Jason Schiller ([email-masked]) <[email-masked]>

On 24-feb-2006, at 19:47, Jason Schiller ([email-masked]) wrote:

> I am baffled by the fact that Service Provider Operators have come  
> out in
> this forum, at the IAB IPv6 multihoming BOF, and other places, and  
> have
> explained how they and their customers use traffic engineering, yet up
> until now, shim6 has not tried to provide thier needed functionality.

I think what we have here is a disconnect between what's going on in  
the wg (and the multi6 design teams) and what's visible from the  
outside.

I remember MANY conversations, in email and during meetings, about  
traffic engineering. And for me, there has never been any question  
that traffic engineering is a must-have for any multihoming solution.  
Paying for two (or more) links and only being able to use one 99% of  
the time is simply too cost-ineffective. And just maybe we can  
convince people that shim6 makes for good multihoming even though it  
doesn't give you portable address space, but it's never going to fly  
if the TE is unequivocally worse than what we have today. (And I've  
said this in the past.)

However, for a number of reasons this isn't all that apparent to an  
outside observer:

- part these conversations were on closed design team lists, private  
email or in (design team/interim) meetings (for instance, only 3% of  
the messages in multi6 for the last couple of years mention TE)
- I don't think any of us, but at least not me, saw TE as a  
particularly hard-to-solve problem
- TE can only happen if the base mechanisms are well understood, so  
were focussing on those first

> This is part of the reason more service providers are not envolved  
> in the
> IETF.

"You have to do what we want or we'll boycot you"? This way, only  
five people would be active in the IETF...

> The other part as KC Claffy points out is cost
> http://www.arin.net/meetings/minutes/ARIN_XVI/ 
> ppm_minutes_day1.html#anchor_8

[Debugging broken PMTUD over IPv6 at ARIN]

I'm not sure which statement about cost you are referring to, or why.

> Some history...

> 1. RFC-3582 attempts to document IPv6 multi-homing requirements.

Forget this RFC, it exists because of the inner workings of the IETF;  
it doesn't do anything useful in the real world.

> 2. I tried to document the basic building block for TE.
> -Primary / backup
> -Load all links as best as possible
> -Use best path
> -any combination of these basic building blocks
> -additional ability to increase or decrease traffic for any of these

> The response I get is do people actully do this?

What I said was that I didn't understand why people want to have two  
links and then have the second one sit idle until the first fails. I  
know people want this because I used to configure this for customers  
when I worked at UUNET NL. But my thinking is that if you have  
multiple links, you'll want to use all of them.

> 3. IAB IPv6 multi-homing BOF

> It seems to me that Service Provider Operators made a very clear  
> statememt
> at the BOF.
> -Traffic engineering is needed day 1.

I agree with that one.

>   * Traffic engineering should not be an end host decesion, but an
>     end site (network level) decesion [managing on the end host is
>     the wrong place]

If hosts can do congestion control they can do traffic engineering.  
The only question is how to get site-wide policies into hosts.

>   * Traffic engineering needs to support in-bound and out-bound
>     traffic mamagement

Sure.

>   * Traffic engineering needs to be allowed by transit ASes as well
>     as end site ASes [don't leave all ISP TE in the hans of our  
> customers]

Are you saying that if I have two ISPs, those get to decide how I  
balance my traffic over them? What if they turn this knob in opposite  
directions?

Although I think it's useful for networks in the middle to be able to  
express some pushback, I'm not sure if this is implementable for  
sites that don't have a full BGP feed, and if it turns out this is  
impossible or too hard to implement, I don't think that's a fatal  
flaw. You don't get to push back on single homed customers either.

> -First hit is critical
>   * establishing shim6 after the session starts doesn't help
>     short lived sessions

I'm not sure where this comes from. Since shim6 doesn't come into  
play until there is a failure, and failures are too rare to be  
meaningful in TE, the shim6 failover protocol itself is fairly  
meaningless for TE. What we need is mechanisms to do source/ 
destination address selection in a way that can be traffic  
engineered. Length of individual sessions is meaningless as shim6  
doesn't work per-session. Most short sessions are part of a longer  
lived interaction (i.e., a user visiting a WWW server and retrieving  
dozens or hundreds of resources over the course of a dozen seconds to  
many minutes).

>   * Keeping shim6 state on the end host doesn't scale for content
>     providers.  A single server may have 30,000 concurrent TCP  
> sessions

Right. So there is precedent for storing state for 30000 instances of  
"something". Servers are getting a lot faster and memory is getting  
cheaper so adding a modest amount of extra state for longer lived  
associations shouldn't be problematic.

(Visit a run of the mill content provider and see how many 100 byte  
GIFs they send you over HTTP connections that have 700 - 1200 byte  
overhead and of course all have high performance extensions turned on  
for extra bandwidth wastage.)

> -Maybe 8+8 / GSE seems to be a better starting point to support  
> transit AS
>  TE and to avoid the first hit problem and still allow for an "easy"
>  multi-homing for consumer customers ?

8+8/GSE won't work: it doesn't tell us how to do failover, it  
requires changes to TCP and other upper layer protocols, and the  
locator-identifier binding is insecure. On the surface, it may seem  
that TCP/IP as we know it today is insecure to begin with, so the GSE/ 
8+8 insecurity doesn't add new holes. Unfortunately, it does. With IP  
as it is today, when I want to pretend that I'm www.yahoo.com at the  
IP level, I have to send out packets with a source address that  
matches www.yahoo.com (which is generally easy) but I also have to  
make sure that packets toward that address get back to me. On an  
insecure (wireless) LAN this is easy, but once the packet ends up at  
an ISP network, this isn't easy to do, and almost impossible to hide.  
With 8+8 on the other hand, I can just create a packet that has the  
Yahoo identifier, and my locator. This way, I can very easily get my  
victim to talk to me while thinking he is talking to Yahoo.

Funny thing: you can look at shim6 as a next generation of GSE/8+8 (16 
+16) that removes the problems listed above.

> The response sounds to me that shim6 wg is finally interested in
> considering decent TE as a "requirement".  Yay!  But I am concerned  
> about
> what Operators and IETF folk think is "decent TE",

Let me speak for myself and speculate a bit: what we should do is  
have multihomed sites publish SRV (or versy similar) records with two  
values: a "strong" value that allows primary/backup mechanisms, and a  
"weak" value that allows things like 60% of all sessions should go to  
this address and 40% to that one.

Then, before a host sets up a session it consults a local policy  
server that adds local preferences to the remote ones and also  
supplies the appropriate source address that goes with each  
destination address. New mechanisms to distribute this information  
have been proposed in the past, but there is already a service that  
is consulted before the start of most sessions, so it makes sense to  
reuse that service. (No prizes for guessing what service I'm getting  
at.)

This would allow for pretty fine tuned incoming TE, as long as the  
other end doesn't have a reason to override the receiving site's  
preferences.

I also imagine some use of measured and synthetic round trips to  
select the "fast" path where possible. This can't be done in BGP: BGP  
is pretty good at avoiding very bad paths, but it's not so good at  
selecting the best ones.

> |Yuck, you should never announce more specifics for this.

> Please beleive the DFZ Service Provider's when the explain how  
> they, and
> their customers do TE.

I believe that they do it, because I see that the global routing  
table has increased by 16% last year. I have to admit that I've done  
this myself from time to time, but only if AS path prepending (or  
changing the origin attribute) wouldn't result in something  
reasonable. It seems to me that for many people deaggregating is the  
default these days. And then not just breaking a /20 into two /21s,  
but go for broke and announce 16 /24s, who cares?

> Take the picture below where cust1 has connectivity to UUNET and
> at&t.  cust2 has connectivity to Sprint and L(3).  UUNET, at&t,  
> Sprint,
> and L(3) all peer with each other.

>        UUNET---Sprint
>       / |   \  /   | \
>      /  |    \/    |  \
> cust1   |    /\    |   cust2
>      \  |   /  \   |  /
>       \ |  /    \  | /
>        at&t------L(3)

> -cust1 pay a flat rate to at&t and per packet to UUNET.
> -cuts1 prefers to use the at&t link as primary (in and out bound)
> -cust1 sends BGP comunity 701:80 to UUNET, and UUNET sets a local  
> pref of
>  80 on behalf of the customer

> -cust2 has more out bound than in bound traffic.
> -cust2 wants to load share all out bound traffic across both links
> -cust2 wants traffic delivered to it over the "best" path

> Traffic from cust1 to cust2
> ---------------------------
> 1. cust1 will send the traffic to at&t
> 2. at&t will decide if it is better to deliver traffic to cust2
>    via the exit point to L(3) or via the exit point to Sprint
> 3A. If at&t thinks the Sprint exit is more prefered, then
>     Sprint should deliver traffic to its customer over the
>     Sprint-cust2 link
> 3B. If at&t thinks the L(3) exit is more prefered, then
>     L(3) should deliver traffic to its customer over the
>     L(3)-cust2 link

> *In this case at&t can do some TE.  Sprint may actully be
>  closer or further than L(3), or at&t may  artificially
>  distance or shorten Sprint, or may force certain prefixes
>  to prefer Sprint or L(3) [this is usally only the case for
>  purchased transit and not peering]

So far so good. Note that with shim6, it's possible (although  
probably hard to do in practice) for cust1 to use four different  
paths: uunet->sprint, at&t->l3, but also uunet->l3 and at&t->sprint.  
So in the presence of congestion or scenic routing, there is a much  
better chance for the customer to utilize the optimal path.

This is both good and bad for ISP/carriers as the customer experience  
improves, but customers will more actively avoid "bad" paths so they  
can't get away with those as much as they can now.

> Traffic from cust2 to cust1
> ---------------------------
> 1. cust2 will spray traffic to Sprint and at&t
> 2A. UUNET is not advertising cust1 routes to Peers as
>     the best path is learned from a Peer and UUNET does
>     not provide transit to Peers.
> 3A. L(3) and Sprint will forward traffic to at&t
> 4A. at&t will forward traffic to their customer over the
>     at&t-cust1 link

> 2B. at&t is customers of UUNET instead of a Peer.
>     In this case UUNET will advertise the cust1
>     prefic to L(3) and Sprint.
> 3B. L(3) and Sprint will choose the best exit and
>     send the traffic either to at&t or to UUNET
> 4B. Traffic sent to UUNET will be delivered to at&t as
>     UUNET will honor the customer's low local pref community
>     Traffic sent to at&t (either from UUNET or L(3) or Sprint)
>     will be delivered over the at&t-cust1 link.

With shim6 and the TE I outlined earlier a correspondent would be  
able to override the receiving site's wishes, which isn't possible in  
the above scenario. However, it's unlikely that correspondents will  
do this on a wide scale unless there is some reason why this is  
beneficial to them.

> In shim6 if cust1 chooses the Sprint IP address as the destination
> then all transit ASes must deliver the traffic via Sprint.  Transit
> ASes have no capability to understand the destination lives behind
> both Sprint and L(3), and threfore deliver the traffic to L(3) if
> the L(3) exit point is better.

If the shim6 sites have access to a BGP feed they can still do  
outgoing traffic engineering as usual. However, I expect that only a  
subset of all shim6 sites will bother to run BGP so many will have to  
depend on end-to-end information which will often be better than what  
BGP supplies, and sometimes (a lot) worse, but never as easy to  
change by ASes in the middle.

> Transit AS TE is more critical in the case of moderate sized  
> transit AS
> that is purchasing transit from multiple upstreams.  Especally when  
> links
> are cost prohibative.  Take a large South American ISP that has 16  
> STM-1s,
> where 4xSTM1 use the Americas 2 oceananic cable system to up stream
> transit provider1, 4xSTM1 use the Emergia oceananic cable system to up
> stream transit provider1, 4xSTM1 use the Americas 2 oceananic cable  
> system
> to up stream stream transit provider2, and 4xSTM1 use the Americas 2
> oceananic cable system to up stream stream transit provider2.  Now  
> imagine
> that your most important customer who always complains about latency
> should always use the Americas 2 oceananic cable system to up stream
> tranist provider1.  Also imagine all other traffic should load all the
> other links as equally as possible.  and given that any one or more  
> links
> fail, all the links should be loaded as equally as possible.  Note:  
> This
> is just one example of a real world customer.

Unfortunately this is incompatible with hop-by-hop forwarding for  
outgoing traffic from the customer. Obviously this can be solved both  
today and with shim6 using MPLS or similar.

Delivery-date: Fri, 24 Feb 2006 18:48:20 +0000
Date: Fri, 24 Feb 2006 13:47:11 -0500 (EST)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
To: Iljitsch van Beijnum <[email-masked]>
Cc: Mikael Abrahamsson <[email-masked]>, shim6-wg <[email-masked]>

I am baffled by the fact that Service Provider Operators have come out in
this forum, at the IAB IPv6 multihoming BOF, and other places, and have
explained how they and their customers use traffic engineering, yet up
until now, shim6 has not tried to provide thier needed functionality.

This is part of the reason more service providers are not envolved in the
IETF.  The other part as KC Claffy points out is cost
http://www.arin.net/meetings/minutes/ARIN_XVI/ppm_minutes_day1.html#anchor_8

So you end up with a working group that is heavily weighted by networks
that provide service to consumer customers.  Maybe there does need to be
two solutions, one for consumers that supports simple fail-over on the end
host.  This makes some sense for consumer networks as the end host
operator, and the network operator is the same person.  Usally the CPE
lacks customer access and usally does not support advanced routing
capabilities.  Neither do consumers want to bother with purchasing an ASN,
or the difficulties of understanding and configuring complicated routing
policies.

On the other hand complex TE preformed at the customer's network level 
is an absolute necessity for business customers.  

Some history...    

1. RFC-3582 attempts to document IPv6 multi-homing requirements.
   
I thought the problem was that this RFC was more of a laundry list of some
of the current IPv6 multi-homing/TE usages, and didn't provide the "basic
building blocks" of multi-homing.  It was later pointed out to mee that
these are not "requirements" but "goals" meaning not needed for a useful
shim6 deployment.

2. I tried to document the basic building block for TE.
-Primary / backup
-Load all links as best as possible
-Use best path
-any combination of these basic building blocks
-additional ability to increase or decrease traffic for any of these

The response I get is do people actully do this?

3. IAB IPv6 multi-homing BOF

It seems to me that Service Provider Operators made a very clear statememt
at the BOF.
-Traffic engineering is needed day 1.
  * Traffic engineering should not be an end host decesion, but an 
    end site (network level) decesion [managing on the end host is 
    the wrong place]
  * Traffic engineering needs to support in-bound and out-bound 
    traffic mamagement
  * Traffic engineering needs to be allowed by transit ASes as well
    as end site ASes [don't leave all ISP TE in the hans of our customers]

-First hit is critical
  * establishing shim6 after the session starts doesn't help 
    short lived sessions
  * Keeping shim6 state on the end host doesn't scale for content
    providers.  A single server may have 30,000 concurrent TCP sessions
    
-Maybe 8+8 / GSE seems to be a better starting point to support transit AS
 TE and to avoid the first hit problem and still allow for an "easy" 
 multi-homing for consumer customers ?

The response sounds to me that shim6 wg is finally interested in
considering decent TE as a "requirement".  Yay!  But I am concerned about
what Operators and IETF folk think is "decent TE", based on past and
current experience:

|Date: Fri, 23 Sep 2005 00:47:22 +0200
|From: Iljitsch van Beijnum <[email-masked]>
|To: Jason Schiller <[email-masked]>
|Cc: shim6-wg <[email-masked]>
|Subject: Re: addition of TLV to locator ID or locator ID set
|
|On 22-sep-2005, at 23:23, Jason Schiller ([email-masked]) wrote:
|
|>> These days, 85% of the internet is reachable over either two or
|>> three hops. So "best" is largely meaningless here.
|
|> I'm not sure I agree that shortest AS path is mostly uselees
|> because most
|> of the Internet is only a few ASes away.  I think generally people
|> still
|> think its better to transit two ASes instead of three.
|
|What I meant is that there is a group of people for which 85% of the
|world is 2 ASes away and a group for which 85% is 3 ASes away.
|
|Five years ago or so you could do some traffic engineering with path
|prepending, these days it's largely useless because the AS hierarchy
|is so flat.
|
|> BGP has many mechinisms to alter the loading of links.  By default
|> you get
|> shortest AS path in bound.  You can get primary back-up using local
|> pref
|> to different up stream ISPs,
|
|Do people really buy lines just to use them as backups? I never
|understood this.
|
|> you can get primary back up whith a single upstream using MED,
|
|You can still do that with the shim in effect.
|
|> our you can load share by splitting your announcements
|> across you links.
|
|Yuck, you should never announce more specifics for this.

Please beleive the DFZ Service Provider's when the explain how they, and
their customers do TE.  

I do agree that IPv4 style TE through advertising multiple more specifics
to the global routing table will likely not scale in the IPv6
world.  Unfortunately, this is the only tool in the tool box to accomplish
the necessary TE in IPv4.  And IPv6 multi-homing is providing no such tool
to obtain similar results.  This is one of the reasons that operators
are saying shim6 is broken, lets just de-aggregate in IPv6.

If you think "you should never announce more specifics for this" then
provide a better tool to accomplish the TE needs.  But don't just say you
shouldn't do this and remove the functionality.  

|On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:
|
|> Date: Fri, 24 Feb 2006 12:08:42 +0100
|> From: Iljitsch van Beijnum <[email-masked]>
|> To: Geoff Huston <[email-masked]>
|> Cc: [email-masked]
|> Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
|>
|> On 26-okt-2005, at 18:08, Geoff Huston wrote:
|>
|> > Public thanks to Dave, Geoff, Vijay, Ted and Jason for their
|> > involvement in bringing shim6 to the NANOG conference.
|>
|> I just looked at the stream and I can't say that this made me vary
|> happy. </understatement>
|>
|> Some of the comments made were nothing short of ridiculous, with
|> people claiming authority over the traffic engineering decisions made
|> by their _customers_.

OK, let me try this end site AS / transit AS TE thing again...

Take the picture below where cust1 has connectivity to UUNET and
at&t.  cust2 has connectivity to Sprint and L(3).  UUNET, at&t, Sprint,
and L(3) all peer with each other.

       UUNET---Sprint
      / |   \  /   | \
     /  |    \/    |  \
cust1   |    /\    |   cust2
     \  |   /  \   |  /
      \ |  /    \  | /
       at&t------L(3)

-cust1 pay a flat rate to at&t and per packet to UUNET. 
-cuts1 prefers to use the at&t link as primary (in and out bound)
-cust1 sends BGP comunity 701:80 to UUNET, and UUNET sets a local pref of
 80 on behalf of the customer 

-cust2 has more out bound than in bound traffic.  
-cust2 wants to load share all out bound traffic across both links
-cust2 wants traffic delivered to it over the "best" path

Traffic from cust1 to cust2
---------------------------
1. cust1 will send the traffic to at&t
2. at&t will decide if it is better to deliver traffic to cust2
   via the exit point to L(3) or via the exit point to Sprint
3A. If at&t thinks the Sprint exit is more prefered, then 
    Sprint should deliver traffic to its customer over the 
    Sprint-cust2 link
3B. If at&t thinks the L(3) exit is more prefered, then
    L(3) should deliver traffic to its customer over the
    L(3)-cust2 link

*In this case at&t can do some TE.  Sprint may actully be
 closer or further than L(3), or at&t may  artificially 
 distance or shorten Sprint, or may force certain prefixes
 to prefer Sprint or L(3) [this is usally only the case for
 purchased transit and not peering]

Traffic from cust2 to cust1
---------------------------
1. cust2 will spray traffic to Sprint and at&t
2A. UUNET is not advertising cust1 routes to Peers as
    the best path is learned from a Peer and UUNET does
    not provide transit to Peers.
3A. L(3) and Sprint will forward traffic to at&t
4A. at&t will forward traffic to their customer over the
    at&t-cust1 link

2B. at&t is customers of UUNET instead of a Peer.
    In this case UUNET will advertise the cust1 
    prefic to L(3) and Sprint.
3B. L(3) and Sprint will choose the best exit and
    send the traffic either to at&t or to UUNET
4B. Traffic sent to UUNET will be delivered to at&t as
    UUNET will honor the customer's low local pref community
    Traffic sent to at&t (either from UUNET or L(3) or Sprint)
    will be delivered over the at&t-cust1 link.

*In this second case (B) L(3) and Sprint can choose to send
 the traffic to either UUNET or at&t.  Both L(3) and Sprint
 have some TE capabilites in choosing UUNET or at&t.  UUNET 
 may actually be closer or further than at&t from the L(3)
 or Sprint perspective.  L(3) or Sprint may artificially 
 distance or shorten UUNET or at&t, or may force certain 
 prefixes to prefer UUNET or at&t [this is usally only the
 case for purchased transit and not peering]

In shim6 if cust1 chooses the Sprint IP address as the destination
then all transit ASes must deliver the traffic via Sprint.  Transit 
ASes have no capability to understand the destination lives behind 
both Sprint and L(3), and threfore deliver the traffic to L(3) if
the L(3) exit point is better. 

Transit AS TE is more critical in the case of moderate sized transit AS
that is purchasing transit from multiple upstreams.  Especally when links
are cost prohibative.  Take a large South American ISP that has 16 STM-1s,
where 4xSTM1 use the Americas 2 oceananic cable system to up stream
transit provider1, 4xSTM1 use the Emergia oceananic cable system to up
stream transit provider1, 4xSTM1 use the Americas 2 oceananic cable system
to up stream stream transit provider2, and 4xSTM1 use the Americas 2
oceananic cable system to up stream stream transit provider2.  Now imagine
that your most important customer who always complains about latency
should always use the Americas 2 oceananic cable system to up stream
tranist provider1.  Also imagine all other traffic should load all the
other links as equally as possible.  and given that any one or more links 
fail, all the links should be loaded as equally as possible.  Note: This
is just one example of a real world customer.
    
|On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:
|> If you have several links to the internet, you don't want one to sit
|> idle while another is congested. So traffic engineering is an
|> essential part of multihoming. Now obviously most ISPs are multihomed
|> themselves so they want to do their own TE. That's completely
|> legitimate. However, that doesn't mean that they get to decide how
|> their customers can do TE. If a customer sends traffic to an ISP and
|> that traffic conforms to SLAs and accepted congestion control
|> methods, the ISP should deliver the packets. That's their business.
|> But some people at the NANOG BOF expressed a different view: "the law
|> of large numbers only works if I control the large numbers". And:
|> "most small businesses can't single home properly". To which a
|> certain ex area director replied: "that doesn't stop them from doing
|> it twice.
|> [...] just like us they're all idiots".

Obvoisuly from my examples above I disagree with your characterization of
how customers and transit ASes actually use inter-AS TE in the real
world.  This is at least as is seen from the perspective of one provider
and its customers.  From what I can tell in talking to the other large
carriers, they mostly do the same, but I certainly can't speak for them.

___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 Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

> Date: Fri, 24 Feb 2006 13:33:58 +0100
> From: Iljitsch van Beijnum <[email-masked]>
> To: Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
> 
> On 24-feb-2006, at 12:26, Mikael Abrahamsson wrote:
> 
> >>> 1) Traffic engineering, traffic engineering and traffic engineering
> 
> >> I guess we'll have to take this one to heart. I believe this means  
> >> decent traffic engineering must be in the first version of the specs.
> 
> > I think it should be considered whose problem shim6 is aimed at  
> > solving and whose side shim6 development should be one. ISPs want  
> > to do TE, customers want to work around it (perhaps).
> 
> > In my book, TE is evil and ISPs should be lossless and efficient.  
> > TE is just evil patching.
> 
> In my book, traffic engineering is chapter 6.  :-)
> 
> You can read it online: http://www.oreilly.com/catalog/bgp/chapter/ 
> ch06.html
> 
> If you have several links to the internet, you don't want one to sit  
> idle while another is congested. So traffic engineering is an  
> essential part of multihoming. Now obviously most ISPs are multihomed  
> themselves so they want to do their own TE. That's completely  
> legitimate. However, that doesn't mean that they get to decide how  
> their customers can do TE. If a customer sends traffic to an ISP and  
> that traffic conforms to SLAs and accepted congestion control  
> methods, the ISP should deliver the packets. That's their business.  
> But some people at the NANOG BOF expressed a different view: "the law  
> of large numbers only works if I control the large numbers". And:  
> "most small businesses can't single home properly". To which a  
> certain ex area director replied: "that doesn't stop them from doing  
> it twice.
> [...] just like us they're all idiots".
> 
> Unfortunately, these days, many people take TE to mean "break up my  
> portable address block in small parts". That is one way to do it, and  
> an effective one, but also the least scalable one.
> 
> > I like the fact that shim6 discourages end users from getting their  
> > own address space and AS number just because of redundancy and  
> > multihoming, and I definately like the fact that I will be able to  
> > move between IPs due to mobility, and keep my ssh session up during  
> > this move. I really hate shutting down my ssh sessions just because  
> > I go from wireless to wired mode. Without "screen" I would hate it  
> > even more.
> 
> Well, shim6 isn't really mobility, although you could probably do  
> this with it.
> 
> > This has to take precedence over some ISPs desire to do TE. Perhaps  
> > if their routers could be smaller and simpler due to smaller TCAM  
> > space need, they could afford to upgrade their links instead of  
> > doing a lot of TE to work around the bw problem. Their job is to  
> > move the packets the customer sends to them, and shim6 is an  
> > enduser feature and they shouldn't bother about it.
> 
> Amen to that.
> 
> And I hope they're not using TCAMs for the (entire) IP routing table,  
> because these suckers use lots of power and scale linearly.
> 

Delivery-date: Fri, 24 Feb 2006 12:34:26 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Fri, 24 Feb 2006 13:33:58 +0100
To: Mikael Abrahamsson <[email-masked]>

On 24-feb-2006, at 12:26, Mikael Abrahamsson wrote:

>>> 1) Traffic engineering, traffic engineering and traffic engineering

>> I guess we'll have to take this one to heart. I believe this means  
>> decent traffic engineering must be in the first version of the specs.

> I think it should be considered whose problem shim6 is aimed at  
> solving and whose side shim6 development should be one. ISPs want  
> to do TE, customers want to work around it (perhaps).

> In my book, TE is evil and ISPs should be lossless and efficient.  
> TE is just evil patching.

In my book, traffic engineering is chapter 6.  :-)

You can read it online: http://www.oreilly.com/catalog/bgp/chapter/ 
ch06.html

If you have several links to the internet, you don't want one to sit  
idle while another is congested. So traffic engineering is an  
essential part of multihoming. Now obviously most ISPs are multihomed  
themselves so they want to do their own TE. That's completely  
legitimate. However, that doesn't mean that they get to decide how  
their customers can do TE. If a customer sends traffic to an ISP and  
that traffic conforms to SLAs and accepted congestion control  
methods, the ISP should deliver the packets. That's their business.  
But some people at the NANOG BOF expressed a different view: "the law  
of large numbers only works if I control the large numbers". And:  
"most small businesses can't single home properly". To which a  
certain ex area director replied: "that doesn't stop them from doing  
it twice.
[...] just like us they're all idiots".

Unfortunately, these days, many people take TE to mean "break up my  
portable address block in small parts". That is one way to do it, and  
an effective one, but also the least scalable one.

> I like the fact that shim6 discourages end users from getting their  
> own address space and AS number just because of redundancy and  
> multihoming, and I definately like the fact that I will be able to  
> move between IPs due to mobility, and keep my ssh session up during  
> this move. I really hate shutting down my ssh sessions just because  
> I go from wireless to wired mode. Without "screen" I would hate it  
> even more.

Well, shim6 isn't really mobility, although you could probably do  
this with it.

> This has to take precedence over some ISPs desire to do TE. Perhaps  
> if their routers could be smaller and simpler due to smaller TCAM  
> space need, they could afford to upgrade their links instead of  
> doing a lot of TE to work around the bw problem. Their job is to  
> move the packets the customer sends to them, and shim6 is an  
> enduser feature and they shouldn't bother about it.

Amen to that.

And I hope they're not using TCAMs for the (entire) IP routing table,  
because these suckers use lots of power and scale linearly.

Delivery-date: Fri, 24 Feb 2006 11:52:02 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Fri, 24 Feb 2006 12:51:39 +0100
To: Tony Li <[email-masked]>

On 17-feb-2006, at 0:23, Tony Li wrote:

>>> I don't think we are very far away from allowing the routers to  
>>> change
>>> the source locator in shim6, but I don't feel we collectively
>>> (IETF+NANOG etc) know how useful such a capability would be.

>> I'm not convinced that letting routers change the source locator in
>> shim6 would be a good solution. This will add new mechanisms on the
>> routers, force them to maintain some additional state and could  
>> lead to
>> a NATification of IPv6.

> Shim6 is a NATification of IPv6 anyway, it just colocates the NAT
> function with the individual host.

> Letting the routers change the the source locator turns out to be  
> very,
> very useful in aiding the access ISP in doing source address  
> filtering.
>    Without that, we have the choice of unintentionally sending packets
> with an inappropriate source locator to our access ISP, or warping our
> IGP's and forwarding algorithms to work based on the source locator.
> The latter is a major shift away from where IP has been since 1983.

There are two problems with allowing routers to rewrite source  
addresses:

1. The routers must know which packets are "legacy" and can't have  
their source address changed vs which packets are controlled by shim6  
or another mechanism that can handle rewritten source addresses.

2. In current shim6, only previously negotiated source addresses may  
be used, which means the shim6-enabled hosts in a site and the  
rewriting routers must coordinate their efforts so correspondent  
hosts don't see unexpected source addresses.

The first issue is readily solvable by simply having shim6 hosts put  
a magic value in the upper 64 bits of the source address that  
indicates "rewriting permitted".

The second issue is a bit more complex but not fatally so, IMO.

So if we want to, we can explore source address rewriting.

The reason we haven't done so (or, at least, the reason I haven't  
pushed this) is that it doesn't solve anything in the short term  
because we can't depend on this capability in the forseeable future,  
so shim6 must also work without the rewriting capability present.

Delivery-date: Fri, 24 Feb 2006 11:30:55 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about R1bis
Date: Fri, 24 Feb 2006 12:30:37 +0100
To: marcelo bagnulo braun <[email-masked]>

On 8-nov-2005, at 19:20, marcelo bagnulo braun wrote:

> One of the issues that are still open is how to detect context loss  
> and recover it.

[...]

> At this point, this would work as follows:
> - Regular IPv6 communication is established between A and B
> - Shim context is set up
> - Peer A losses the context
> - a failure occurs

I this case, A doesn't have any shim state so it can't do anything  
except time out. B on the other hand will notice a lack of incoming  
packets (unless the failure is unidirectional B -> A, that would be  
bad here) so after a while a reachability exploration will be started.

It's been a while, so I'm not entirely sure if the way this is  
written down now implies that a reachability exploration  
automatically gives A all of B's addresses so that it's possible for  
control packets to start flowing again from A to B, but if it isn't,  
obviously we can add this.

At this point A will need to receive some context and security info  
from B and we're back in business. (If B uses a different address B'  
towards A then B has to prove that B' is the same host as B, but  
that's what we have HBA for.)

Delivery-date: Fri, 24 Feb 2006 11:26:53 +0000
Date: Fri, 24 Feb 2006 12:26:38 +0100 (CET)
From: Mikael Abrahamsson <[email-masked]>
To: [email-masked]
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Organization: People's Front Against WWW

On Fri, 24 Feb 2006, Iljitsch van Beijnum wrote:

>> 1) Traffic engineering, traffic engineering and traffic engineering
>
> I guess we'll have to take this one to heart. I believe this means decent 
> traffic engineering must be in the first version of the specs.

I think it should be considered whose problem shim6 is aimed at solving 
and whose side shim6 development should be one. ISPs want to do TE, 
customers want to work around it (perhaps).

In my book, TE is evil and ISPs should be lossless and efficient. TE is 
just evil patching.

I like the fact that shim6 discourages end users from getting their own 
address space and AS number just because of redundancy and multihoming, 
and I definately like the fact that I will be able to move between IPs due 
to mobility, and keep my ssh session up during this move. I really hate 
shutting down my ssh sessions just because I go from wireless to wired 
mode. Without "screen" I would hate it even more.

This has to take precedence over some ISPs desire to do TE. Perhaps if 
their routers could be smaller and simpler due to smaller TCAM space need, 
they could afford to upgrade their links instead of doing a lot of TE to 
work around the bw problem. Their job is to move the packets the customer 
sends to them, and shim6 is an enduser feature and they shouldn't bother 
about it.

-- 
Mikael Abrahamsson    email: [email-masked]

Delivery-date: Fri, 24 Feb 2006 11:10:25 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
Date: Fri, 24 Feb 2006 12:08:42 +0100
To: Geoff Huston <[email-masked]>

On 26-okt-2005, at 18:08, Geoff Huston wrote:

> Public thanks to Dave, Geoff, Vijay, Ted and Jason for their
> involvement in bringing shim6 to the NANOG conference.

I just looked at the stream and I can't say that this made me vary  
happy. </understatement>

Some of the comments made were nothing short of ridiculous, with  
people claiming authority over the traffic engineering decisions made  
by their _customers_. Understanding of what shim6 is and what it does  
was sorely lacking.

> The messages I heard were:

> 1) Traffic engineering, traffic engineering and traffic engineering

I guess we'll have to take this one to heart. I believe this means  
decent traffic engineering must be in the first version of the specs.

>     - do NOT put this in the hands of the end system, this needs to
> be site level, or at the very least the site needs to be able to
> override the end system's decisions.

This is doable if we support proxy shim6 in middleboxes.

Doing shim6 in a middlebox for a legacy host may be challenging, but  
worthwhile because it makes deployment so much easier.

But doing part of shim6 in middleboxes (the part that relates to  
traffic engineering and other policy stuff) and part on the hosts  
shouldn't be too hard.

> 2) The first hit is of critical importance to content providers (many
> of whom couldn't legitimately justify a /32).  Hunting through DNS to
> find a locator that works won't fly.

Right. So how do we solve this? Second shim? Shim-before-syn?

> 3) It was good to hear in a widespread forum that shim6 is not
> expected to be THE only multihoming solution.  However, we were left
> uninformed as to where the other work is going on.

Time to dust off geographical aggregation, I guess.

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

Delivery-date: Thu, 23 Feb 2006 13:49:11 +0000
Date: Thu, 23 Feb 2006 05:47:10 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Defining and updating CT(peer)

marcelo bagnulo braun wrote:

>>> -- Receiving I1 packets in I1-SENT state
> [...]
> i think we are fine if we keep the optimization i.e. the host sends a R2 
> as a reply to the received I1 but it waits until the reception of that 
> R2 packet to define the CT(peer), ok?

That might make sense.

I was thinking that having I1 always result in a R1 (independent of any 
state) would certainly be easier to describe.
But that would probably mean that the case of crossing I1s end up 
resulting in 8 packets being exchanged.

So the optimization to return a R2 in this case makes sense.

>>> -- Receiving I1 packets in I2-SENT state
> [...]
> I think we can keep the exchange as it is, i.e. the host replies with an 
> R2, but the difference is that it defines CT(peer) upon the reception of 
> the R2 packet and not upon the reception of the I1 packet, ok?

ok

>> Question: does this mean that we can skip verifying anything against 
>> the existing context state? (such as checking that the locators are 
>> part of Ls(peer) and Ls(local))
> 
> well we are checking that the CGA/HBA corresponds to the ULID of the 
> existing context and the the signature/locator set of the HBA 
> corresponds to that CGA/HBA

So should we uniformly avoid checks on Ls(peer) for the reception of 
messages that we verify using CGA/HBA in any case?

> what we are not checking is that the locators used in this packet belong 
> to the existent Ls(peer), but i don't think we need that, since we are 
> verifying that the ULID matches and the CGA/HBA is associated with the 
> ULID, and this should be enough to allow the peer to redefine the Ls(peer)

ok

    Erik

Delivery-date: Thu, 23 Feb 2006 11:25:55 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Defining and updating CT(peer)
Date: Thu, 23 Feb 2006 12:25:29 +0100
To: Erik Nordmark <[email-masked]>

El 22/02/2006, a las 17:25, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>> # Level of security targeted
>> -- The proposed level of security for this operation is that CT(peer)=20=

>> is only updated when the shim control message that
>> requests so contains a token that proves prior contact and that
>> the source locator can be verified that it is securely bound
>> to the source ULID of the context, does this seems a
>> reasonable requirement?
>
> Sounds like a reasonable requirement.
>
>
>> # Analysis of different packet processing
>> -- Receiving I1 packets in ESTABLISHED state
>> In case that a host receives a I1 packet for a context that
>> is in the ESTABLISHED state, the draft assumes that the peer
>> has lost context and triggers the context recovery mechanism,
>> which consists in  updating the CT(peer) to the one contained
>> in the I1 packet and then sending an R2 packets.
>> I guess this is too weak.
>> Probably we need to improve this, dropping the optimization
>> and requiring the full 4-way exchange in this scenario. This
>> means updating the CT(peer) only on I2 packets. This would
>> have the additional cost that it would take 2 more packets
>> to create the loss context in this case.
>> Suggested change: drop optimization for this case and go
>> for R1, I2, R2 procedure
>
> So in this case the host would behave as if the context was in IDLE=20
> state (not create/update any state and sending an R1).
>

yes

>> -- Receiving I1 packets in I1-SENT state
>> In this case, we are in the case of simultaneous shim6
>> context establishment. In this case the draft states that
>> CT(peer) is set to the value contained in the received I1
>> message. Again, this would open the door to the
>> considered DoS attack. Since the hosts will receive a R2
>> message later anyway, the proposed solution is to set
>> CT(peer) only upon the reception of the R2 message (which
>> must be validated with the nonce)
>> Proposed change: not  setting CT(peer) upon the reception
>> of I1 in I1-SENT  state but do it upon the reception of R2
>
> ok.
> Should the host *send* a R2 packet, or send an R1 in this case?
>

i think we are fine if we keep the optimization i.e. the host sends a=20
R2 as a reply to the received I1 but it waits until the reception of=20
that R2 packet to define the CT(peer), ok?

>> -- Receiving I1 packets in I2-SENT state
>> This case is similar to the previous one. It affects the
>> case of almost simultaneous context establishment. The
>> draft states that CT(peer) is defined upon the reception
>> of an I1 message in I2-SENT state. This present similar
>> threats as the previous case, and the proposed solution
>> is the same. Define CT(peer) upon the reception of R2.
>> Proposed change: not setting CT(peer) upon the reception
>> of I1 in I2-SENT, but do it with R2
>
> ok.
> What should the host send?

I think we can keep the exchange as it is, i.e. the host replies with=20
an R2, but the difference is that it defines CT(peer) upon the=20
reception of the R2 packet and not upon the reception of the I1 packet,=20=

ok?
>
>> -- Receiving I1 packets in I2bis-SENT state
>> Similar to the previous case, this scenario occurs when
>> one end attempts to create a context that the other end
>> is trying to recover. The draft states that CT(peer)
>> must be updated upon the reception of an I1 message,
>> but this open the possibility of the considered attack.
>> The solution is again to update CT(peer) upon the
>> reception of the R2 message.
>> Proposed change: not updating CT(peer) upon the reception
>> of I1 in I2bis-SENT, but do it with R2
>
> ok
>
>> - Receiving I2 packets in ESTABLISHED state
>> No action is performed upon the reception on an I2
>> packet with a different CT(peer) in ESTABLISHED state
>> However, this needs to be changed in order to support
>> context recovery, since we are in the case where the
>> peer is trying to establish a context that the local
>> node has already available. So, upon the reception of
>> a I2 message for a context that is in ESTABLISHED
>> state, the node needs to verify the validator, and the
>> relation between the source locator and the source
>> identifier (i.e. HBA/CGA check) and if it succeeds,
>> then it must update CT(peer) and eventually the other
>> information related to the context e.g. the locator set
>
> ok
>
>> Question: does this means that we update the existent
>> context with the new information or that we create a
>> new context with the new information and we let the
>> old context to age and expire?
>
> What's important is that the old information should be gone once the=20=

> I2 is processed.
>

ok

> Whether this is implemented as a complete replacement of the existing=20=

> state, or by discarding the old state and creating a new context, is=20=

> an implementation detail.
>

>> Proposed change: upon the reception of an I2 message
>> in ESTABLISHED state, the validator and ULID-locator
>> context is verified and the context state information
>> (CT(peer) and Ls(peer)) is updated
>
> Question: does this mean that we can skip verifying anything against=20=

> the existing context state? (such as checking that the locators are=20
> part of Ls(peer) and Ls(local))

well we are checking that the CGA/HBA corresponds to the ULID of the=20
existing context and the the signature/locator set of the HBA=20
corresponds to that CGA/HBA

what we are not checking is that the locators used in this packet=20
belong to the existent Ls(peer), but i don't think we need that, since=20=

we are verifying that the ULID matches and the CGA/HBA is associated=20
with the ULID, and this should be enough to allow the peer to redefine=20=

the Ls(peer)

> If this was a normal context establishment there wouldn't be any such=20=

> check, since there wouldn't be any context when we receive I2. Hence=20=

> in that case it is sufficient to check the validator and the locator=20=

> set against HBA/CGA, so one could argue those checks should be=20
> sufficient in any state when we receive an I2 message.
>

right

regards, marcelo

Delivery-date: Thu, 23 Feb 2006 10:57:59 +0000
Cc: Shinta Sugimoto <[email-masked]>, [email-masked], "Jason Schiller ([email-masked])" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: More TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Thu, 23 Feb 2006 11:56:53 +0100
To: Erik Nordmark <[email-masked]>

El 22/02/2006, a las 16:50, Erik Nordmark escribi=F3:
>
>> - OTOH, another option is to use the routing system for policy, in=20
>> particular, we allow source address rewriting by exit routers and we=20=

>> use the intra site routing to divert the outgoing traffic according=20=

>> to policy and we use the source address rewriting to make the source=20=

>> address compatible with ingress filters and eventually if the peer is=20=

>> willing to reply to the address it received as source locator in=20
>> incoming packet, this mechanism could be used to influence the=20
>> locator selection of the other end. In any case, i think that the=20
>> host may need to be allowed to avoid address rewriting especially due=20=

>> to fault tolerance issues, since the host probably knows better.
>
> There certainly are interactions between the hosts' knowledge of what=20=

> is working and an implicit or explicit signal from the routers. Did=20
> you have specific fault tolerance issues in mind?
>

Well, i was worried about aggregation and the limitations that this may=20=

have w.r.t. fault tolerance, but now thinking it over, i am not sure if=20=

this would be a problem.
I was thinking about the following scenario:
Suppose that we allow site exit routers to rewrite source address=20
prefixes.
Suppose now that we inject BGP feed to the multihomed site routers
Now, through BGP routers know which egress path is available and=20
preferred to reach a given destiantion and if this egress path brokes=20
they can select another one through BGP route selection. This would=20
provide BGP fault tolerance. (Clearly when BGP decides to use a=20
different egress path, a different source address prefix is to be used=20=

in order to deal with ingress filters, hence we need source address=20
prefix rewriting)

The limitation of BGP fault tolerance is aggregation. I mean, BGP will=20=

continue announcing a prefix as reachable, even if a particular address=20=

of that prefix just went down.
My concern was that BGP may prefer a given route to a prefix, even if=20
the particular address where the traffic is addressed to is=20
unreachable.

However this may not such a problem, since in order to overcome this=20
failure, what is probably needed is to change the _destiantion_ address=20=

(not the source address, which is influenced by BGP).

So, probably the distribution of tasks would be:
- both host and routers work on fault tolerance
- the site routers through BGP information select the best available=20
exit path (and select the source address prefix rewriting it=20
accordingly to the exit path selected)
- when the host detects a failure, it just selects an alternative=20
destination address (and then the site routing system will select a new=20=

egress route accordingly)

I am not sure if additional host-router interaction is needed (i.e. not=20=

sure if need to allow the host to disable rewriting as i was claiming=20
before)

In addition, we can configure routers to express policy, like=20
preferring some egress routes towards certain destiantion, just as is=20
currently done. this would affect how the traffic for a given=20
destiantion is routed.
In addition, we may need to influence the host when it performs the=20
destiantion address selection, in order to be able to express policy=20
with respect to which destiantion addresses to prefer. This can=20
probably be done with the RFC3484 policy table (if it is considered=20
when performing locator selection, which we haven't discussed yet)

>> Allowing rewriting the shim6 control packets could be useful=20
>> especially to benefit from the knowleddge available in the routing=20
>> system of which routes are available to the destiantion and not=20
>> forcing the usage of the ISP associated to the source address=20
>> selected by the host, but i am not sure about the complexity of=20
>> supporting this...
>
> Which is why I was going to try to write it up in a separate I-D - to=20=

> see how complex it might be and also understand the issues and=20
> benefits around it a bit more.
>

yes, this would be helpful indeed

regards, marcelo

>    Erik
>

Delivery-date: Wed, 22 Feb 2006 21:59:03 +0000
Date: Thu, 23 Feb 2006 08:58:19 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

For some reason this post of Erik's got caught by the list manager.

The list manager software evidently saw the pattern of the words
"change" and "adres" (spelled correctly of course) in the body of the
message and tried to execute the message as a list command. Too
clever by half if you ask me!

  Geoff

 >Message-ID: <[email-masked]>
 >Date: Wed, 22 Feb 2006 07:41:05 -0800
 >From: Erik Nordmark <[email-masked]>
 >To: Olivier Bonaventure <[email-masked]>
 >CC: David Meyer <[email-masked]>, marcelo bagnulo braun <[email-masked]>,
  >       Shinta Sugimoto <[email-masked]>, [email-masked]
 >Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

Olivier Bonaventure wrote:

 > I'm not convinced that letting routers change the source locator in
 > shim6 would be a good solution. This will add new mechanisms on the
 > routers, force them to maintain some additional state and could lead to
 > a NATification of IPv6.

Shim6 already allows the shim to change what goes in the adress fields
in the IPv6 header, but since this is undone by the shim at the
receiving end, it doesn't have the downsides of NAT. Thus I don't see
having the routers rewriting what goes in the IPv6 address fields (for a
packet which has IPPROTO_SHIM6) as leading no more NATs.

 > Despite this, I have the impression that the IETF did not consider
 > entreprise or ISP networks when developping shim6. The basic assumption
 > has been that hosts perform all decisions related to shim6 autonomously
 > - host select the source and destination locators
 > - host check the availability of the path and switch to another one in
 > case of problems

I think the multi6 and shim6 WGs did consider site multihoming i.e. a
site where the host endpoints live. (It didn't consider a transit ISP
being multihomed; only traffic that terminate in the site was considered.)

One could argue that the IETF work hasn't taken concerns like traffic
engineering into account. But apart from Jason's concerns, which
resulted in at least being able to carry preferences end-to-end, we
haven't seen much in terms of TE requirements. (And everybody seems to
agree that multiple PA prefixes means that the TE possibilities are
different than in the single prefix + BGP that is the norm for
multihoming in IPv4.)

One might ask why all the pieces of shim6 happen in the hosts and not
also in the routers or other parts of the network. The reason is that in
order to provide shim6 we have to have some changes in the host, in
order to ensure that the IPv6 addresses that the transport protocols and
the applications use are indeed restored at the peer. (The alternative
of a "proxy" shim implementation without any changes on the host seem to
imply an IPv6 NAT as part of the proxy function, i.e., applications that
have problems with IPv4 NATs would most likely have problems with such a
proxy/NAT shim solution.)

Given that both endpoints have to be modified, there is significant
deployment advantage if we don't *require* other changes in the network.
But I think having shim6 work better, e.g., better TE support or faster
failover, by modifying or adding elements in the network is something
that we should consider.

 > Letting hosts select paths in multihomed scenarios where a enduser is
 > attached to both ADSL and CATV networks is useful. However, if the host
 > belongs to an entreprise network, then the managers of the entreprise
 > network will probably want to influence the selection of the source and
 > destination locators. One possibility to do this would be to tune the
 > DNS servers (assuming the hosts perform DNS requests before sending
 > data) or define a protocol, used in the entreprise network to perform
 > the address selection on behalf of the endsystem. Such a protocol was
 > proposed a few years ago :

DNS servers help with destination address selection, in particular if we
can move applications to use DNS SRV records. But it doesn't help with
source address selection.

 > 
http://www2.info.ucl.ac.be/people/delaunoi/ietf/draft-de-launois-multi6-naros-00.txt 

Such a mechanism is one of the options. But we have to be careful to not
assume it, because folks want to deploy shim6 without assuming some such
service in the network. For instance, I don't think we should have a
shim6 host by default try to send packets to such a service, since the
service might not be deployed in which case that would just slow things
down.

It also isn't clear to me to what extent a network service which helps
with locator selection fits with the desire of deferred context
establishment; if the TE requirements are such that we want to invoke
such a function (i.e., communicate to the service in the network) before
we send the first packet (e.g., TCP SYN).

It would be interesting to see what's necessary to satisfy the TE
requirements. It might be that the combination of
   - optional but recommended use of DNS SRV records (for initial
destination address selection taking the peer site's priority and weight
into account) and
   - optional router rewriting of locators in shim6 packets
would be sufficient.
It certainly would avoid adding additional message exchanges before
communication starts.

 > Letting hosts detect failures is a nice approach in the ADSL+CATV
 > environment. In an entreprise network, the border router could receive
 > information about the failure (e.g. reception of BGP withdraw) and
 > inform the endsystems in the network.

The host has some knowledge (based on observing the bidirectional
traffic, whether done by the transport protocols or by the shim itself)
which the border routers do not passes (the routes could be asymmetric
etc), and the border routers has the BGP information which the hosts do
not possess. Thus ideally we'd like to combine this knowledge.

One way to do this is to have the border routers somehow signal the
hosts. But I'm not sure whether an explicit signal message (ICMP error?)
requires some security between the border routers and the hosts in the
site; the hosts today have no idea of the identify of the border routers.
A way to implicitly convey this is instead of rely on (border) router
rewriting of the source address field.
I don't think we  understand the tradeoffs between those, and any other,
approaches.

 > I think that shim6 will have to consider issues that arise when
 > thousands of multihomed hosts are in the same entreprise or campus network.

What do you see as additional requirements?
As the shim is currently specified the worst-case message overhead for
the shim is small. (With deferred context establishment some number of
packets will be exchanged between the pair of IP addresses before the
shim does it 4 packet setup exchange, and failure detection has close to
zero extra packets when the ULP traffic is bidirectional).

It is somewhat inefficient to have thousands of hosts each independently
detect that e.g., their address in prefix P1 no longer works. Which is a
reason (in addition to TE) why some explicit or implicit signal from the
(border) routers would be interesting.

     Erik

Delivery-date: Wed, 22 Feb 2006 16:27:03 +0000
Date: Wed, 22 Feb 2006 08:25:42 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Defining and updating CT(peer)

marcelo bagnulo braun wrote:
> # Level of security targeted
> 
> -- The proposed level of security for this operation is that CT(peer) is 
> only updated when the shim control message that
> requests so contains a token that proves prior contact and that
> the source locator can be verified that it is securely bound
> to the source ULID of the context, does this seems a
> reasonable requirement?

Sounds like a reasonable requirement.

> # Analysis of different packet processing
> 
> -- Receiving I1 packets in ESTABLISHED state
> 
> In case that a host receives a I1 packet for a context that
> is in the ESTABLISHED state, the draft assumes that the peer
> has lost context and triggers the context recovery mechanism,
> which consists in  updating the CT(peer) to the one contained
> in the I1 packet and then sending an R2 packets.
> I guess this is too weak.
> Probably we need to improve this, dropping the optimization
> and requiring the full 4-way exchange in this scenario. This
> means updating the CT(peer) only on I2 packets. This would
> have the additional cost that it would take 2 more packets
> to create the loss context in this case.
> 
> Suggested change: drop optimization for this case and go
> for R1, I2, R2 procedure

So in this case the host would behave as if the context was in IDLE 
state (not create/update any state and sending an R1).

> -- Receiving I1 packets in I1-SENT state
> 
> In this case, we are in the case of simultaneous shim6
> context establishment. In this case the draft states that
> CT(peer) is set to the value contained in the received I1
> message. Again, this would open the door to the
> considered DoS attack. Since the hosts will receive a R2
> message later anyway, the proposed solution is to set
> CT(peer) only upon the reception of the R2 message (which
> must be validated with the nonce)
> 
> Proposed change: not  setting CT(peer) upon the reception
> of I1 in I1-SENT  state but do it upon the reception of R2

ok.
Should the host *send* a R2 packet, or send an R1 in this case?

> -- Receiving I1 packets in I2-SENT state
> 
> This case is similar to the previous one. It affects the
> case of almost simultaneous context establishment. The
> draft states that CT(peer) is defined upon the reception
> of an I1 message in I2-SENT state. This present similar
> threats as the previous case, and the proposed solution
> is the same. Define CT(peer) upon the reception of R2.
> 
> Proposed change: not setting CT(peer) upon the reception
> of I1 in I2-SENT, but do it with R2

ok.
What should the host send?

> -- Receiving I1 packets in I2bis-SENT state
> 
> Similar to the previous case, this scenario occurs when
> one end attempts to create a context that the other end
> is trying to recover. The draft states that CT(peer)
> must be updated upon the reception of an I1 message,
> but this open the possibility of the considered attack.
> The solution is again to update CT(peer) upon the
> reception of the R2 message.
> 
> Proposed change: not updating CT(peer) upon the reception
> of I1 in I2bis-SENT, but do it with R2

ok

> - Receiving I2 packets in ESTABLISHED state
> 
> No action is performed upon the reception on an I2
> packet with a different CT(peer) in ESTABLISHED state
> However, this needs to be changed in order to support
> context recovery, since we are in the case where the
> peer is trying to establish a context that the local
> node has already available. So, upon the reception of
> a I2 message for a context that is in ESTABLISHED
> state, the node needs to verify the validator, and the
> relation between the source locator and the source
> identifier (i.e. HBA/CGA check) and if it succeeds,
> then it must update CT(peer) and eventually the other
> information related to the context e.g. the locator set

ok

> Question: does this means that we update the existent
> context with the new information or that we create a
> new context with the new information and we let the
> old context to age and expire?

What's important is that the old information should be gone once the I2 
is processed.
Whether this is implemented as a complete replacement of the existing 
state, or by discarding the old state and creating a new context, is an 
implementation detail.

> Proposed change: upon the reception of an I2 message
> in ESTABLISHED state, the validator and ULID-locator
> context is verified and the context state information
> (CT(peer) and Ls(peer)) is updated

Question: does this mean that we can skip verifying anything against the 
existing context state? (such as checking that the locators are part of 
Ls(peer) and Ls(local))
If this was a normal context establishment there wouldn't be any such 
check, since there wouldn't be any context when we receive I2. Hence in 
that case it is sufficient to check the validator and the locator set 
against HBA/CGA, so one could argue those checks should be sufficient in 
any state when we receive an I2 message.

> - Receiving I2 packets in I1-SENT state
> 
> This scenario is the case of simultaneous context
> establishment and the draft states that the context
> state remains unchanged (waiting for the R2 message)
> so no problem in this case and no change is required.
 >
> - Receiving I2 packets in I2-SENT and I2bis-SENT state
> 
> I can't find a scenario for this case to make sense,
> but the draft states that no change is performed upon
> the reception of an I2 message in this state, so i
> guess no threats are involved.
> 
> (Note that even if we update the context information upon
> the reception of an I2 message, this wouldn't present a
> threat since I2 contains a validator to check prior contact
> and HBA/CGA information to check ULID-locator relation)
> 
> - Receiving R2 packets in ESTABLISHED state
> 
> No action is performed upon the reception on an R2 packet
> with a different CT(peer) in ESTABLISHED state
> 
> - Receiving R2 packets in I1-SENT, I2-SENT and I2bis-SENT
> 
> The draft states that the host would need to update the
> CT(peer) upon the reception of an R2 packet in I1-SENT,
> I2-SENT and I2bis-SENT state. this does not presents a
> security issue because R2 packet must contain the
> Initiator Nonce which was included in previously sent
> messages
> 
> - Receiving I2bis packets in ESTABLISHED state
> 
> No action is performed upon the reception on an I2bis
> packet with a different CT(peer). Moreover, this situation
> is unlikely to happen, since no R1bis message can be generated
> for an existent context, so no proper I2bis validator can be
> obtained, in order to generate a I2bis message for an
> established context
> 
> - Receiving I2bis packets in I1-SENT state state
> 
> We are in the simultaneous context establishment situation
> and the draft states that no context information is updated,
> since this is deferred upon the reception of the R2 message
> 
> - Receiving I2bis packets in I2-SENT and I2bis-SENT state
> 
> I can't identify which scenario would result in this case,
> but in any case, the context information is not updated upon
> the reception of an I2bis message in this case, so no threat
> is involved
> 
> 

ok

    Erik

Delivery-date: Wed, 22 Feb 2006 15:52:07 +0000
Date: Wed, 22 Feb 2006 07:50:25 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Shinta Sugimoto <[email-masked]>, [email-masked], "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: More TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

marcelo bagnulo braun wrote:

>> Thus at a gross level I see two different ways to factor the system:
>> A. An ID->loc lookup system which takes some policy into account.
>>
> 
> I am not sure what do you have in mind for this.... are you thinking 
> about something like Naros?

If I don't misremember, Naros only allows the handling of the policy of 
the local site, i.e. doesn't have a mechanism to allow the peer's site 
(or transits) to express their policy.
Approach A) was trying to capture what I thought Jason was suggesting, 
which I think is the ability to collect policy information from the peer 
site, so that the choice of the destination locator can be influenced by 
the peer.

AFAIK we don't actually have a protocol which can do this.

> I think i am not completelly following you...
> I mean i can see two different approaches to shim6 policing:
> - on one hand, an endpoint based approach where, somehow the policy is 
> pushed to the hosts themselves (e.g. using a DHCP option). In this case, 
> the policy is used by the host at two instances: first, when it starts a 
> communication, it uses the policy information to select the ULIDs and 
> eventually its own locators. Second, the host may try to push the policy 
> to the peer, using the locator preference option. In this option, there 
> is no need to support address rewriting by the exit routers, since 
> policy is pushed from the policy manager to the hosts themselves.

Depends how dynamic the policy is. If we want to handle more dynamic 
locator policies, the locator rewriting by the routers would be one option.

> - OTOH, another option is to use the routing system for policy, in 
> particular, we allow source address rewriting by exit routers and we use 
> the intra site routing to divert the outgoing traffic according to 
> policy and we use the source address rewriting to make the source 
> address compatible with ingress filters and eventually if the peer is 
> willing to reply to the address it received as source locator in 
> incoming packet, this mechanism could be used to influence the locator 
> selection of the other end. In any case, i think that the host may need 
> to be allowed to avoid address rewriting especially due to fault 
> tolerance issues, since the host probably knows better.

There certainly are interactions between the hosts' knowledge of what is 
working and an implicit or explicit signal from the routers. Did you 
have specific fault tolerance issues in mind?

> Allowing rewriting the shim6 control packets could be useful especially 
> to benefit from the knowleddge available in the routing system of which 
> routes are available to the destiantion and not forcing the usage of the 
> ISP associated to the source address selected by the host, but i am not 
> sure about the complexity of supporting this...

Which is why I was going to try to write it up in a separate I-D - to 
see how complex it might be and also understand the issues and benefits 
around it a bit more.

    Erik

Delivery-date: Wed, 22 Feb 2006 11:53:40 +0000
Date: Wed, 22 Feb 2006 03:52:25 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], Spencer Dawkins <[email-masked]>, Geoff Huston <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

marcelo bagnulo braun wrote:
>=20
> El 16/02/2006, a las 20:26, Erik Nordmark escribi=F3:
>=20
>> Geoff Huston wrote:
>>> In response to your query (and Erik can correct me if I'm wrong) It=20
>>> is my understanding in the specification that whenever the ULID pair =

>>> is used as the locator pair then the SHIM6 extension header (the=20
>>> context value) is omitted from the packet. This allies to the initial=
=20
>>> contact pahse, and also in any subsequent time when the SHIM selects =

>>> the ULID pair as the current locator pair.
>>
>> Correct. But folks have also suggested that we should allow the shim6 =

>> extension header all the time i.e., even if the receiver doesn't have =

>> to rewrite the locators. I don't see any harm in allowing this for=20
>> folks that want their packets to be bigger...
>>
>=20
> FWIW, i think may be useful if we ever want to support prefix rewriting=
=20
> by exit routers. I mean, if we want to support this, the way i=20
> understand this could be, is that endpoints would establish a shim=20
> session between them and then they would let routers to rewrite source =

> prefixes for those packets belonging to the established context. In tha=
t=20
> case, it would necesary for the ednpoint to identify those packets that=
=20
> belong to the shim context hence they should include the payload header=
=20
> even if they are using the ulids as locators.
>=20
> So, i would suggest to allow this behaviour, or at least not explicitly=
=20
> forbidding it.

Agreed,

Should we add some more explicit text on this in the document?

    Erik

Delivery-date: Wed, 22 Feb 2006 11:39:40 +0000
Date: Wed, 22 Feb 2006 03:37:20 -0800
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: review of draft-ietf-shim6-proto-03.txt, sections 1-2

Thanks for your comments. I've used them to try to make things more 
clear in the document. See below regarding my question about renumbering 
ULIDs and whether we should add some requirement to the document for that.

Jari Arkko wrote:
> 
> Technical:
> 
>> However, it
>>   might turn out that the shim6 protocol can be a useful component,
>>   e.g., for route optimization in the context of host mobility.
>>
> Not sure why the usefulness would have to be limited
> to route optimization.

As I read it, the text doesn't limit where it might be useful - it just 
gives a concrete example.

I don't have an example where shim6 might help outside of route 
optimization, since the HA-type interaction for tunnel management is 
likely to have slightly different requirements. But the intent isn't 
that the text limit its possible application for mobility.

> Maybe "... can be a useful component in the context of
> host mobility". Or don't say anything.

How about:
    This proposal does not attempt
    to solve the, perhaps related, problem of host mobility.  However, it
    might turn out that the shim6 protocol can be a useful component for
    future host mobility solutions, e.g., for route optimization.

>>   This potential source for confusion can be avoided if we require that
>>   any communication using a ULID must be terminated when the ULID
>>   becomes invalid (due to the underlying prefix becoming invalid).  If
>>   that behavior is desired, it can be accomplished by explicitly
>>   discarding the shim state when the ULID becomes invalid.  The context
>>   recovery mechanism will then make the peer aware that the context is
>>   gone, and that the ULID is no longer present at the same locator(s).
>>  
>>
> Invalid... or if you move away from the link on which you had
> the ULID? The HBA draft does allow dynamic case, so it seems
> that this can happen.

There is a tradeoff between the robustness of the communication when 
there are failures, and how the protocol reacts to ULIDs "disappearing". 
(Note that the text in 03 doesn't clearly say that when the locator 
becomes invalid it isn't a problem; 04 will make this more clear.)

A couple of cases to consider:
1. The host remains attached to one or more interfaces, and the Router 
Advertisement messages (or DHCPv6, if it is used for address 
autoconfiguration), explicitly indicate that the prefix is now invalid.

2. The host looses its connectivity on one interface (e.g., it walked 
out of range of the 802.11 access point) but retains connectivity on 
some other interface (e.g, the GPRS interface). This means that the host 
wouldn't notice a sudden decrease in the valid lifetime on the 802.11 
interface (it can't receive any RAs). But it the host kills 
communication that uses the 802.11 prefix in the ULID then we are likely 
to loose the shim6 robustness benefits for host multihoming.

3. Like in case #2, but while the host is detached from the 802.11 link, 
the valid prefix lifetime (which is 30 days by default in RFC 2461), 
expires.

Thus in case #1 and #3 it might make sense to force communication that 
uses the now invalid ULID to fail. But in #2 I think we should retain it 
  until the prefix valid lifetime expires.

It might be that most of these tradeoffs appear when we have host 
multihoming, because for site multihoming one would expect the prefix 
advertisements to be more "consistent"; the multiple prefixes are likely 
to be advertised by the same routers in the same router advertisement 
messages (i.e., we'd have only case #1 to worry about for site multihoming.)

So should we make a stronger recommendation in this space?

> Editorial:
> 
> Introduction: I'd prefer writing this in a style that focuses
> less on what the history with the WGs and approaches
> was, and more on the what the protocol does. Same for
> the abstract, e.g., s/The SHIM6 working group is specifying
> a layer 3 shim approach/The SHIM6 protocol is a layer 3 shim/

Yep. We got that comment from Geoff as well, but I'd missed fixing the 
abstract.

>>   15.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . .   81
>>   19.   Possible Protocol Extensions . . . . . . . . . . . . . . .   88
>>  
>>
> These should probably go to an appendix.

ok

>>   identifiers to locators, such a name space isn't necessary (and
>>   furthermore doesn't seem to help) to solve the multihoming problem.
>>  
>>
> I thought "is not" is better style than "isn't" (and same for
> "doesn't"), but I'm this is not my native language...

Neither is it mine. But as I understand it, "isn't" is the more normal 
form, and "is not" can be used for emphasis.

>>   and Provide Independent IP addresses.
>>
> s/Provide/Provider/
> 
>> The format allows adding additional notions of
>>   "metrics" over time.  But this is merely a place holder; even in
>>   order to use this there would have to be a mechanism by which the
>>   host can find out what preference values to use, either statically
>>   (e.g., some new DHCPv6 option) or dynamically.
>>
> Is the latter part talking about the preferences in general
> or just the additional notions of metrics? For the former,
> even if the protocol is fully defined now, one still has to
> find out the preferences locally. For the latter, presumably
> the receiver just ignores the unknown metrics, if any.

In general. I'll change the text to "But the Locator Preference option 
is merely a place holder when it comes to providing traffic engineering, 
...".

For the latter, the format might be suboptimal, since we are not 
requiring that the first 3 bytes of each element be understood by 
implementations confirming to what's in this document. Thus I think we 
should add this in section 5.14.3 specifying the Locator Preference 
option format:
<t>This document doesn't specify the format when the Element length is more
than three, except that any such formats MUST be defined so that the first
three octets are the same as in the above case, that is,
a of a 1 octet flags field followed by a 1 octet priority field,
and a 1 octet weight field.</t>

>>   Context tag         Each end of the context allocates a context tag
>>
> Capitalized or not? Some of the other terms are not, and here we have
> inconsistent capitalization.

The intent was to have lower case "context tag" refer to the general 
concept, and have capitalized names like "Initiator Context Tag" to 
refer to the specific instances when naming a field in a packet or option.

>>   Forked Instance Identifier (FII) In order to handle context forking,
>>
> add <vspace blankLines='1'/>

ok. s/1/0/ to be consistent with the other long terms.

    Erik

Delivery-date: Sun, 19 Feb 2006 18:57:32 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Defining and updating CT(peer)
Date: Sun, 19 Feb 2006 19:27:33 +0100

Hi,

One of the issues that Shinta brought up in his review is the potential 
attack concerning updating CT(peer) with shim6 control packets.
We have been discussing this point with Erik, and this is an attempt to 
summarize my understanding of the problem so far.
Any comments are welcome

Defining and updating CT(peer)

# Issue description

-- When a shim6 context is established (or in its way to be 
established), the reception of shim6 control packets may result
in defining/updating the CT(peer) associated to the shim6 context.
This may pose some security concerns if this operation is not
properly secured.

# Threat related to this operation:

-- The main threat identified is that this could allow an attacker 
to change the CT(peer) of a context leading to an DoS
attack, since subsequent packets with the new CT won't be
recognized by the receiver

# Level of security targeted

-- The proposed level of security for this operation is that 
CT(peer) is only updated when the shim control message that
requests so contains a token that proves prior contact and that
the source locator can be verified that it is securely bound
to the source ULID of the context, does this seems a
reasonable requirement?

# Scope

-- Messages involved
I1, I2, R2 and I2bis contain CT information so they must be
considered in this analysis
R1 does not contain CT information, so no need to consider it
R1bis contain CT(packet) which does not result in updating
CT(peer), so there is no need to consider it neither for this
particular threat.

-- States involved
This concern is clearly raised when the CT(peer) for the
context is defined. So, the following states are
affected:
- ESTABLISHED
- I2bis-SENT

In addition, when a state is being created, the reception
of different messages result in the definition of CT(peer)
for that context. In this case, the situation is somehow
different, since CT(peer) is not defined yet, but the
result of the attack is similar, since CT(peer) may end
up with a fake value. This can occur in the following states:
- I1-SENT
- I2-SENT

# Summary of the proposed approach

The idea is not to update nor define CT(peer) upon the
reception of messages that don't contain information of
prior contact. So, the proposal is to defer the
update/define of the CT(peer) until the reception of:
- R2 messages received in I1-SENT, I2-SENT or I2bis-SENT
   states. The R2 contains an valid Initiator nonce
   that proves prior exchange and has a valid ULID-locator
   relation proven through HBA/CGA information, or
- I2 messages received in ESTABLISHED state. The I2
   contains a valid validator and
   a valid ULID-locator relation proven through HBA/CGA
   information.

In this approach, it is still possible for an attacker to
assign an invalid CT(peer) for an established context, but
in order to do that, the attacker needs to be able to
perform a 4-way handshake from one of the locators securely
bound (through HBA/CGA technique) to the used ULID

Note: next the complete case by case analysis is detailed,
so, if you are not really interested i would suggest stop
reading here...

# Analysis of different packet processing

-- Receiving I1 packets in ESTABLISHED state

In case that a host receives a I1 packet for a context that
is in the ESTABLISHED state, the draft assumes that the peer
has lost context and triggers the context recovery mechanism,
which consists in  updating the CT(peer) to the one contained
in the I1 packet and then sending an R2 packets.
I guess this is too weak.
Probably we need to improve this, dropping the optimization
and requiring the full 4-way exchange in this scenario. This
means updating the CT(peer) only on I2 packets. This would
have the additional cost that it would take 2 more packets
to create the loss context in this case.

Suggested change: drop optimization for this case and go
for R1, I2, R2 procedure

-- Receiving I1 packets in I1-SENT state

In this case, we are in the case of simultaneous shim6
context establishment. In this case the draft states that
CT(peer) is set to the value contained in the received I1
message. Again, this would open the door to the
considered DoS attack. Since the hosts will receive a R2
message later anyway, the proposed solution is to set
CT(peer) only upon the reception of the R2 message (which
must be validated with the nonce)

Proposed change: not  setting CT(peer) upon the reception
of I1 in I1-SENT  state but do it upon the reception of R2

-- Receiving I1 packets in I2-SENT state

This case is similar to the previous one. It affects the
case of almost simultaneous context establishment. The
draft states that CT(peer) is defined upon the reception
of an I1 message in I2-SENT state. This present similar
threats as the previous case, and the proposed solution
is the same. Define CT(peer) upon the reception of R2.

Proposed change: not setting CT(peer) upon the reception
of I1 in I2-SENT, but do it with R2

-- Receiving I1 packets in I2bis-SENT state

Similar to the previous case, this scenario occurs when
one end attempts to create a context that the other end
is trying to recover. The draft states that CT(peer)
must be updated upon the reception of an I1 message,
but this open the possibility of the considered attack.
The solution is again to update CT(peer) upon the
reception of the R2 message.

Proposed change: not updating CT(peer) upon the reception
of I1 in I2bis-SENT, but do it with R2

- Receiving I2 packets in ESTABLISHED state

No action is performed upon the reception on an I2
packet with a different CT(peer) in ESTABLISHED state
However, this needs to be changed in order to support
context recovery, since we are in the case where the
peer is trying to establish a context that the local
node has already available. So, upon the reception of
a I2 message for a context that is in ESTABLISHED
state, the node needs to verify the validator, and the
relation between the source locator and the source
identifier (i.e. HBA/CGA check) and if it succeeds,
then it must update CT(peer) and eventually the other
information related to the context e.g. the locator set

Question: does this means that we update the existent
context with the new information or that we create a
new context with the new information and we let the
old context to age and expire?

Proposed change: upon the reception of an I2 message
in ESTABLISHED state, the validator and ULID-locator
context is verified and the context state information
(CT(peer) and Ls(peer)) is updated

- Receiving I2 packets in I1-SENT state

This scenario is the case of simultaneous context
establishment and the draft states that the context
state remains unchanged (waiting for the R2 message)
so no problem in this case and no change is required.

- Receiving I2 packets in I2-SENT and I2bis-SENT state

I can't find a scenario for this case to make sense,
but the draft states that no change is performed upon
the reception of an I2 message in this state, so i
guess no threats are involved.

(Note that even if we update the context information upon
the reception of an I2 message, this wouldn't present a
threat since I2 contains a validator to check prior contact
and HBA/CGA information to check ULID-locator relation)

- Receiving R2 packets in ESTABLISHED state

No action is performed upon the reception on an R2 packet
with a different CT(peer) in ESTABLISHED state

- Receiving R2 packets in I1-SENT, I2-SENT and I2bis-SENT

The draft states that the host would need to update the
CT(peer) upon the reception of an R2 packet in I1-SENT,
I2-SENT and I2bis-SENT state. this does not presents a
security issue because R2 packet must contain the
Initiator Nonce which was included in previously sent
messages

- Receiving I2bis packets in ESTABLISHED state

No action is performed upon the reception on an I2bis
packet with a different CT(peer). Moreover, this situation
is unlikely to happen, since no R1bis message can be generated
for an existent context, so no proper I2bis validator can be
obtained, in order to generate a I2bis message for an
established context

- Receiving I2bis packets in I1-SENT state state

We are in the simultaneous context establishment situation
and the draft states that no context information is updated,
since this is deferred upon the reception of the R2 message

- Receiving I2bis packets in I2-SENT and I2bis-SENT state

I can't identify which scenario would result in this case,
but in any case, the context information is not updated upon
the reception of an I2bis message in this case, so no threat
is involved

Delivery-date: Sat, 18 Feb 2006 16:55:38 +0000
Cc: Shinta Sugimoto <[email-masked]>, [email-masked], "Jason Schiller ([email-masked])" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: More TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Sat, 18 Feb 2006 17:16:34 +0100
To: Erik Nordmark <[email-masked]>

Hi Erik,

El 17/02/2006, a las 19:53, Erik Nordmark escribi=F3:
>
> The total size of the policy would be large. But if it is mostly=20
> static then it might be manageable.
> We can still do load spreading and primary/fallback with a static=20
> policy; the policy can be expressed akin to DNS SRV records with a=20
> priority (for primary/fallback) and a weight (for load spreading), and=20=

> the client of the policy evaluates this.
>

I think this approach is quite attractive, especially becuase it not=20
only applies to SHIM6 traffic (i.e. the traffic of those communications=20=

that have established a SHIM6 session) but it would affect to all the=20
_incoming_ traffic of a multihomed site.
I mean, having a TE tools based on the usage of the SHIM6 protocol=20
(like using the SHIM6 locator prefernces) it would only affect the=20
traffic of the SHIM6 enabled communications, but it would not affect=20
the packets of those communications that will not use or are not yet=20
using the shim6 protocol. OTOH, if the shim6 protocol proves to be a=20
useful TE tool, this may encourage users to establish shim6 sessions,=20
not just to obtain fault tolerance but also to achieve some form of TE.

However, there are tools that may apply to both non-shim and shim=20
traffic, especially:
- DNS SRV records for affecting the traffic of those communications=20
that are externally initiated
- configuring the RFC3484 policy table to affect the traffic of those=20
communications that are internally initiated

more about shim6 based policy below...

> If you want the policy to change due to dynamic events, even if it is=20=

> just based on different policies for different times of day, then=20
> things get hard.
>
> But this also assumes that anybody that connects is allowed to see the=20=

> policy to be able to do the evaluation of what locator to use. That=20
> might run into trouble with existing practices.
>
> An alternative would be to have some TBD mechanism (some new DHCP=20
> option?) for the destination site to distribute its policy (e.g., in=20=

> the form of priorities and weights) to all the hosts in the site, and=20=

> then use shim6 to express those to every peer that connects to a host=20=

> in the site.
>
> Thus at a gross level I see two different ways to factor the system:
> A. An ID->loc lookup system which takes some policy into account.
>

I am not sure what do you have in mind for this.... are you thinking=20
about something like Naros?

> B. An ID->loc lookup system without policy, plus
>    policy distribution within each end site and host-to-host =
exchanging
>    of preferences when they start communicating.
>
> For both approaches there is the question how useful it is to allow=20
> routers to rewrite the source locators.
>
> I know how to build B out of existing components. But B doesn't allow=20=

> a transit ISP to express their policy; only the end sites can do it.
>

> On the other hand, I have no idea what the threat model is for A; how=20=

> to make a distinction between a legitimate ISP on the path, and an=20
> attacker?
>
> Hmm - perhaps we should write this up in an I-D?
> I'm sure there are more details to discuss, and I'd really like to=20
> explore this more to determine whether we need to do shim6=20
> differently.
> And, from my understanding of approach B, the only open question in my=20=

> mind is whether we need to make shim6 allow locator rewriting on its=20=

> I1, R1, etc control messages.
>

I think i am not completelly following you...
I mean i can see two different approaches to shim6 policing:
- on one hand, an endpoint based approach where, somehow the policy is=20=

pushed to the hosts themselves (e.g. using a DHCP option). In this=20
case, the policy is used by the host at two instances: first, when it=20
starts a communication, it uses the policy information to select the=20
ULIDs and eventually its own locators. Second, the host may try to push=20=

the policy to the peer, using the locator preference option. In this=20
option, there is no need to support address rewriting by the exit=20
routers, since policy is pushed from the policy manager to the hosts=20
themselves.
- OTOH, another option is to use the routing system for policy, in=20
particular, we allow source address rewriting by exit routers and we=20
use the intra site routing to divert the outgoing traffic according to=20=

policy and we use the source address rewriting to make the source=20
address compatible with ingress filters and eventually if the peer is=20
willing to reply to the address it received as source locator in=20
incoming packet, this mechanism could be used to influence the locator=20=

selection of the other end. In any case, i think that the host may need=20=

to be allowed to avoid address rewriting especially due to fault=20
tolerance issues, since the host probably knows better.

Allowing rewriting the shim6 control packets could be useful especially=20=

to benefit from the knowleddge available in the routing system of which=20=

routes are available to the destiantion and not forcing the usage of=20
the ISP associated to the source address selected by the host, but i am=20=

not sure about the complexity of supporting this...

Regards, marcelo

>    Erik
>

Delivery-date: Sat, 18 Feb 2006 16:55:07 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: review of draft-ietf-shim6-proto-03.txt, sections 1-2
Date: Sat, 18 Feb 2006 17:30:04 +0100
To: Jari Arkko <[email-masked]>

Hi Jari,

thanks for the feedback, see my inline comments

El 17/02/2006, a las 17:57, Jari Arkko escribi=F3:

>
> Technical:
>
>> However, it
>>   might turn out that the shim6 protocol can be a useful component,
>>   e.g., for route optimization in the context of host mobility.
>>
> Not sure why the usefulness would have to be limited
> to route optimization.
>
> Maybe "... can be a useful component in the context of
> host mobility". Or don't say anything.
>

I guess this is in line with what Geoff was proposing....

>>   This potential source for confusion can be avoided if we require=20
>> that
>>   any communication using a ULID must be terminated when the ULID
>>   becomes invalid (due to the underlying prefix becoming invalid).  =
If
>>   that behavior is desired, it can be accomplished by explicitly
>>   discarding the shim state when the ULID becomes invalid.  The=20
>> context
>>   recovery mechanism will then make the peer aware that the context =
is
>>   gone, and that the ULID is no longer present at the same =
locator(s).
>>
> Invalid... or if you move away from the link on which you had
> the ULID? The HBA draft does allow dynamic case, so it seems
> that this can happen.
>

not sure if i am following you here....

HBA does not support dynamic changes of the locator set... you mean=20
CGA, which is also supported in the draft?

Assuming you meant CGA, we are in the somehow mobile scenario here,=20
right?
But in a mobile scenario, i guess that the ULID would be something like=20=

the HoA, right? if so, when a host leaves the home network, this does=20
not means that you want the sessions established with this ULID to be=20
terminated, since basically what is going on is that the ULID is=20
unreachable as a locator (i.e the node cannot longer be reached at this=20=

locator)

In other words, in the mobile scenarios, i would say that they are=20
about locators becoming unreachable rather than ulids becoming invalid=20=

(which is what i understand this paragraph is about)

> Editorial:
>
> Introduction: I'd prefer writing this in a style that focuses
> less on what the history with the WGs and approaches
> was, and more on the what the protocol does. Same for
> the abstract, e.g., s/The SHIM6 working group is specifying
> a layer 3 shim approach/The SHIM6 protocol is a layer 3 shim/
>
>>   15.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . .  =20=

>> 81
>>   19.   Possible Protocol Extensions . . . . . . . . . . . . . . .  =20=

>> 88
>>
> These should probably go to an appendix.
>
>>   identifiers to locators, such a name space isn't necessary (and
>>   furthermore doesn't seem to help) to solve the multihoming problem.
>>
> I thought "is not" is better style than "isn't" (and same for
> "doesn't"), but I'm this is not my native language...
>
>>   and Provide Independent IP addresses.
>>
> s/Provide/Provider/
>
>> The format allows adding additional notions of
>>   "metrics" over time.  But this is merely a place holder; even in
>>   order to use this there would have to be a mechanism by which the
>>   host can find out what preference values to use, either statically
>>   (e.g., some new DHCPv6 option) or dynamically.
>>
> Is the latter part talking about the preferences in general
> or just the additional notions of metrics?

I think both

> For the former,
> even if the protocol is fully defined now, one still has to
> find out the preferences locally. For the latter, presumably
> the receiver just ignores the unknown metrics, if any.
>

So far the spec only defines a 1,2 or 3 byte preference for a locator.
How these byte(s) can be used to express preferences is leaved=20
undefined.
So, the first thing needed is to define the semantic for these=20
preferences (for each of the 1,2, and 3 byte preference field) and then=20=

in each particular site/hosts the values assigned for each prefix.

I guess that the question is whether you think we should define the=20
semantics of the three preference formats in the spec or it would be=20
enough to leave it undefined?
It is clear that in order to be useful, both peers need to agree in the=20=

semantics of the preference field, but as you mention, a host that=20
receives a preference format that it does not understand, it can just=20
ignore it.

Regards, marcelo=

Delivery-date: Sat, 18 Feb 2006 16:54:37 +0000
Cc: [email-masked], Spencer Dawkins <[email-masked]>, Geoff Huston <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Date: Sat, 18 Feb 2006 16:38:15 +0100
To: Erik Nordmark <[email-masked]>

El 16/02/2006, a las 20:26, Erik Nordmark escribi=F3:

> Geoff Huston wrote:
>> In response to your query (and Erik can correct me if I'm wrong) It=20=

>> is my understanding in the specification that whenever the ULID pair=20=

>> is used as the locator pair then the SHIM6 extension header (the=20
>> context value) is omitted from the packet. This allies to the initial=20=

>> contact pahse, and also in any subsequent time when the SHIM selects=20=

>> the ULID pair as the current locator pair.
>
> Correct. But folks have also suggested that we should allow the shim6=20=

> extension header all the time i.e., even if the receiver doesn't have=20=

> to rewrite the locators. I don't see any harm in allowing this for=20
> folks that want their packets to be bigger...
>

FWIW, i think may be useful if we ever want to support prefix rewriting=20=

by exit routers. I mean, if we want to support this, the way i=20
understand this could be, is that endpoints would establish a shim=20
session between them and then they would let routers to rewrite source=20=

prefixes for those packets belonging to the established context. In=20
that case, it would necesary for the ednpoint to identify those packets=20=

that belong to the shim context hence they should include the payload=20
header even if they are using the ulids as locators.

So, i would suggest to allow this behaviour, or at least not explicitly=20=

forbidding it.

>> i.e. it is my understanding that the packet header is simply an=20
>> implicit "please perform an address substitution" instruction to the=20=

>> other end, and the locator pair plus the context value identifies the=20=

>> particular substitution to a ULID pair that the remote end should=20
>> perform. If the locators are the ULID then no substitution is=20
>> necessary, and no extension header is necessary.
>> At least thats the way I interpret the specification, and I was=20
>> wondering if this should be explicitly stated in the spec.
>
> If we allow the above, it is really "please lookup the context state=20=

> and check if you need to replace the locators", but since replacing=20
> the locator pair with the identical locator pair can be still viewed=20=

> as a replacement, that's just a detail.
>
> Any ideas where such text would best belong in the specification?

imho it would be enough to make sure that the document does not=20
precludes such behaviour...

OTOH, we could include a note in the Sending/receiving payload packets=20=

sections....

Regards, marcelo

>
>    Erik
>
>
>
>

Delivery-date: Fri, 17 Feb 2006 18:55:27 +0000
Date: Fri, 17 Feb 2006 10:53:28 -0800
From: Erik Nordmark <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: Shinta Sugimoto <[email-masked]>, [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-03

Jason Schiller ([email-masked]) wrote:

> The problem here is not not the multiple addresses, but rather a partial
> ID / locator split.  As long as DNS contains information about both the
> identity of the host and the location of the host then the ID and the
> locator are not completely split.  This creates the problem of sifting
> through DNS, and making the solution non-useful for short lived
> sessions.  Also, this problem is what is creating the push for provider
> independent (PI) IPv6 space to avoid "provider lock-in".

I'm not convinced. HIP provides complete separation between identity and 
location, yet it doesn't provide for any more network policy input than 
shim6.

> Imagine instead DNS only has knowledge of the identity, say the host
> address, local subnetting and a way to uniquely identify the site.  The
> source host builds a packet and kicks it to the network without the
> locator information.  The network needs some mechinism to map the site
> identity to one or more locators.  In this model the source host,
> destination host, and DNS system don't care about location.  This is left
> up to some protocol in the network.  On ingress this could be easy for the
> source, just pre-pend your routing locator.  For the destination there
> would need to be some mapping of site ID to one or more locators.  The
> network could pick the most convient locator for the destination.

So we have a domain name to ID lookup using the DNS, and then be have 
some new system/mechanism for looking up an ID and find one or more 
locators, and that new mechanism takes network policy into account. Did 
I get that correct? Or does the new system also take reachability, 
available bandwidth, etc into account?

Has anybody thought about the scaling requirements for this new system?

I would assume one should plan for success, and since the ID/locator 
separation will help with renumbering in addition to multihoming, this 
probably means that the system should scale to every site in the future 
internet using it. (I think during IPng discussion folks were throwing 
around 10^12 "networks" as the requirement, with 3 orders of magnitude 
more hosts.)

We have a system we think can scale to such scales; the DNS, so it is 
probably useful to look at how it scales:
  - hierarchical name space (and when that breaks down as with .com, 
operating the service becomes quite expensive)
  - caching

This is why I think my above question about what information the 
mechanism takes into account is absolutely critical. If it is more or 
less static policy (which can be cached for hours) there is a chance 
that it can be made to scale.
But we might also need the ID name space to have several levels of 
hierarchical allocation to scale the lookup.

But if we need to take into account information that changes more 
frequently, I think we're likely to end up with something that has the 
same scaling issues as BGP. There is no such thing as a free lunch as 
Noel likes to say.

FWIW, once we have the above, we still need a protocol that can provide 
the end-to-end locator agility (without creating a large security hole).

So the question in my mind, while we explore the above, is whether we 
would do shim6 any differently if we had the above ID lookup system.
(Note that there is nothing in shim6 the protocol that assumes that the 
ULIDs are indeed routable addresses; it is merely a convenient way to 
deploy things and it doesn't have the overhead of doing some extra 
lookups for ID->loc mappings.)

> This same site ID to locator mapping protocol could be used by transit
> ASes to rewrite the destination locator information and forward the
> packet towards the destination at an alternate location.  Transit ASes
> that don't wich to perform TE can simply forward the packet and do not
> require the added site/locator state.

Are you assuming that
1) every packet would carry IDs (in addition to the locators)?
2) that the routers would do some lookups on the ID?

There is potentially a simpler way for routers to influence the 
locators, which is just having them do source locator rewriting (as in 
Mike O'Dell's GSE.)
Shim6 already allows this on data packets, and maybe we should make 
shim6 allow that on its "control" packets as well. *If* we allow this, 
and such rewriting is useful, we can get that aspect of GSE behavior 
while having the "first, do no harm" security level present in shim6.

> I'm not sure this scales any better than de-aggregation as all ingress
> routers and any transit routers that want TE will need state to map one or
> more locators to every site.

The total size of the policy would be large. But if it is mostly static 
then it might be manageable.
We can still do load spreading and primary/fallback with a static 
policy; the policy can be expressed akin to DNS SRV records with a 
priority (for primary/fallback) and a weight (for load spreading), and 
the client of the policy evaluates this.

If you want the policy to change due to dynamic events, even if it is 
just based on different policies for different times of day, then things 
get hard.

But this also assumes that anybody that connects is allowed to see the 
policy to be able to do the evaluation of what locator to use. That 
might run into trouble with existing practices.

An alternative would be to have some TBD mechanism (some new DHCP 
option?) for the destination site to distribute its policy (e.g., in the 
form of priorities and weights) to all the hosts in the site, and then 
use shim6 to express those to every peer that connects to a host in the 
site.

Thus at a gross level I see two different ways to factor the system:
A. An ID->loc lookup system which takes some policy into account.

B. An ID->loc lookup system without policy, plus
    policy distribution within each end site and host-to-host exchanging
    of preferences when they start communicating.

For both approaches there is the question how useful it is to allow 
routers to rewrite the source locators.

I know how to build B out of existing components. But B doesn't allow a 
transit ISP to express their policy; only the end sites can do it.

On the other hand, I have no idea what the threat model is for A; how to 
make a distinction between a legitimate ISP on the path, and an attacker?

Hmm - perhaps we should write this up in an I-D?
I'm sure there are more details to discuss, and I'd really like to 
explore this more to determine whether we need to do shim6 differently.
And, from my understanding of approach B, the only open question in my 
mind is whether we need to make shim6 allow locator rewriting on its I1, 
R1, etc control messages.

    Erik

Delivery-date: Fri, 17 Feb 2006 16:57:31 +0000
Date: Fri, 17 Feb 2006 18:57:29 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: review of draft-ietf-shim6-proto-03.txt, sections 1-2

Technical:

> However, it
>   might turn out that the shim6 protocol can be a useful component,
>   e.g., for route optimization in the context of host mobility.
>
Not sure why the usefulness would have to be limited
to route optimization.

Maybe "... can be a useful component in the context of
host mobility". Or don't say anything.

>   This potential source for confusion can be avoided if we require that
>   any communication using a ULID must be terminated when the ULID
>   becomes invalid (due to the underlying prefix becoming invalid).  If
>   that behavior is desired, it can be accomplished by explicitly
>   discarding the shim state when the ULID becomes invalid.  The context
>   recovery mechanism will then make the peer aware that the context is
>   gone, and that the ULID is no longer present at the same locator(s).
>  
>
Invalid... or if you move away from the link on which you had
the ULID? The HBA draft does allow dynamic case, so it seems
that this can happen.

Editorial:

Introduction: I'd prefer writing this in a style that focuses
less on what the history with the WGs and approaches
was, and more on the what the protocol does. Same for
the abstract, e.g., s/The SHIM6 working group is specifying
a layer 3 shim approach/The SHIM6 protocol is a layer 3 shim/

>   15.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . .   81
>   19.   Possible Protocol Extensions . . . . . . . . . . . . . . .   88
>  
>
These should probably go to an appendix.

>   identifiers to locators, such a name space isn't necessary (and
>   furthermore doesn't seem to help) to solve the multihoming problem.
>  
>
I thought "is not" is better style than "isn't" (and same for
"doesn't"), but I'm this is not my native language...

>   and Provide Independent IP addresses.
>
s/Provide/Provider/

>The format allows adding additional notions of
>   "metrics" over time.  But this is merely a place holder; even in
>   order to use this there would have to be a mechanism by which the
>   host can find out what preference values to use, either statically
>   (e.g., some new DHCPv6 option) or dynamically.
>
Is the latter part talking about the preferences in general
or just the additional notions of metrics? For the former,
even if the protocol is fully defined now, one still has to
find out the preferences locally. For the latter, presumably
the receiver just ignores the unknown metrics, if any.

>   Context tag         Each end of the context allocates a context tag
>
Capitalized or not? Some of the other terms are not, and here we have
inconsistent capitalization.

>   Forked Instance Identifier (FII) In order to handle context forking,
>
add <vspace blankLines='1'/>

--Jari

Delivery-date: Fri, 17 Feb 2006 16:31:59 +0000
Cc: Erik Nordmark <[email-masked]>, David Meyer <[email-masked]>, [email-masked], Shinta Sugimoto <[email-masked]>, Olivier Bonaventure <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Fri, 17 Feb 2006 17:30:41 +0100
To: Tony Li <[email-masked]>

Hi Tony,

El 17/02/2006, a las 0:23, Tony Li escribi=F3:
>
> Let me try to correct your impression.  Some of us are very much aware
> of the issues involved and are very interested in supporting more
> functionality at the enterprise boundary.  However, over the years, it
> has been made very clear that performing that type of locator =
selection
> or route selection at the enterprise border is also seen very much as =
a
> form of NAT.
>
> While I happen to disagree with that particular assessment, the simple
> fact of the matter is that the political situation within the IETF at
> present makes any non-host-based solution intractable.  This is
> _precisely_ what drove us towards the shim6 solution.  It is not an
> optimal answer, by any means, IMHO.  It is only the best solution that
> we have been able to reach consensus on.
>

Personally, i agree with Erik that the current solution is not very far=20=

from supporting prefix rewriting by site exit routers.
We have talked about this point several times on this list and i can=20
see three possible approaches (not all of them being so easy to obtain=20=

using the shim)
1) the current scheme where the host performs all the functions of the=20=

shim
2) a full proxy approach where a middle box performs all the shim6=20
stuff on behalf of a set of hosts that don't know anything about the=20
shim and even that they are not aware of multiple addresses. This is=20
the approach most similar to the original GSE. This approach seems to=20
have quite a lot of complexity, mainly because the proxy needs to store=20=

all the shim state related to each ongoing communication.
3) it would also be possible to have a hybrid approach, where the host=20=

is shim enabled and the routers are allowed to rewrite the source=20
address prefixes. In this approach, the security negotiation would be=20
end to end, but the exit path selection would be performed by the=20
routers. So, the shim context is established end to end between the=20
shim capable hosts. In this context the hosts securely negotiate the=20
full set of prefixes available for each end. Once that the shim context=20=

is set up by the peers, then the routers can rewrite the prefix of the=20=

source address. this approach would allow the intra site routing system=20=

to actually determine the exit path and would somehow restore the TE=20
capabilities of the routers. Moreover, fault tolerance can be performed=20=

using BGP rather than using the failure detection mechanism of the=20
shim. (probably there will be some failure modes that won't be detected=20=

through this mean)
The resulting approach would restore part of the BGP based fault=20
tolerance and TE capabilities lost in the current shim6 approach.

Of course there a few things that need to be changed for this to work,=20=

like no privacy support, all the routers need to know all the prefixes=20=

and all the shim6 sessions must have all the prefixes avaialble and so=20=

on, but perhaps it may be interesting to explore it a bit more.

Regards, marcelo

> Regards,
> Tony
>
>
>

Delivery-date: Thu, 16 Feb 2006 23:23:43 +0000
Date: Thu, 16 Feb 2006 15:23:52 -0800
From: Tony Li <[email-masked]>
To: Olivier Bonaventure <[email-masked]>
CC: Erik Nordmark <[email-masked]>, David Meyer <[email-masked]>,  marcelo bagnulo braun <[email-masked]>, Shinta Sugimoto <[email-masked]>,  [email-masked]
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

>> I don't think we are very far away from allowing the routers to change
>> the source locator in shim6, but I don't feel we collectively
>> (IETF+NANOG etc) know how useful such a capability would be.
> 
> I'm not convinced that letting routers change the source locator in
> shim6 would be a good solution. This will add new mechanisms on the
> routers, force them to maintain some additional state and could lead to
> a NATification of IPv6.

Shim6 is a NATification of IPv6 anyway, it just colocates the NAT
function with the individual host.

Letting the routers change the the source locator turns out to be very,
very useful in aiding the access ISP in doing source address filtering.
   Without that, we have the choice of unintentionally sending packets
with an inappropriate source locator to our access ISP, or warping our
IGP's and forwarding algorithms to work based on the source locator.
The latter is a major shift away from where IP has been since 1983.

> Despite this, I have the impression that the IETF did not consider
> entreprise or ISP networks when developping shim6. The basic assumption
> has been that hosts perform all decisions related to shim6 autonomously
> - host select the source and destination locators
> - host check the availability of the path and switch to another one in
> case of problems

Let me try to correct your impression.  Some of us are very much aware
of the issues involved and are very interested in supporting more
functionality at the enterprise boundary.  However, over the years, it
has been made very clear that performing that type of locator selection
or route selection at the enterprise border is also seen very much as a
form of NAT.

While I happen to disagree with that particular assessment, the simple
fact of the matter is that the political situation within the IETF at
present makes any non-host-based solution intractable.  This is
_precisely_ what drove us towards the shim6 solution.  It is not an
optimal answer, by any means, IMHO.  It is only the best solution that
we have been able to reach consensus on.

Regards,
Tony

Delivery-date: Thu, 16 Feb 2006 21:02:51 +0000
Date: Thu, 16 Feb 2006 13:01:24 -0800
From: Erik Nordmark <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

Geoff Huston wrote:
> So with my WG chair hat off, I've reviewed the protocol draft 
> (draft-ietf-shim6-proto-03.txt) and I have prepared a set of comments. 
> They are devided into general approach comments about document and 
> editorial nits.

Thanks very much for your comments (and the editorial nits you sent us 
off line). They'll help make the document clearer.

> 1 - Protocol Overview vs Protocol Specification
> 
> I was confused whether section 4 is a part of the actual protocol 
> specification or whether it was a more general set of overview comments 
> about the characteristics of the particular approach described here. 
> What threw me was a number of MUSTs in section 2, which lead me th think 
> this was part of the specfication, while most of the section was of a 
> more discussive style.
> 
> It appears that sections 7 through 14 are the actual protocol 
> specification, while section 4 is in deed a discussive section rather 
> than a specification.

Section 5 and 6 have normative parts as well.

> One way to clarify this would be to remove the RFC2460 MUSTS SHOULDs, 
> etc from section 4, and use an introductory sentence to note that this 
> is an informal overview of the protocol, and note that the protocol 
> specification is contained in the following sections.

I'll remove those from section 4. Perhaps there will be new 
subsection(s) in section 7 that have the normative parts.

> It may also be useful to encapsulate the current sections 7 though 14 
> into a single section 7 and call it "Protocol Specification", although 
> this is more of a personal style preference.

If we want to capture all the normative text, this would include section 
5, which already have section numbers with 3 parts (e.g., 5.14.1) which 
would end up with 4 parts. So I'd prefer not adopting that style.

> 2 - section 1.4 - Multicast
> 
> Could this be better relocated into section 16 (Implicatons Elsewhere)? 
> with a single line statement in 1.2 ( Non-Goals) that IP multicast is 
> not supported in Shim6?

But I think multicast is supported; it just doesn't need locator 
rewriting because
  - the destination address is an identifier without location semantics 
(it is a multicast group)
  - the source address for multicast must be topologically correct for 
multicast routing (and RPF in particular) to work.

Thus there is no work the shim needs to do for a multicast packet.

That is a rather different statement than a simplistic "multicast is not 
supported". So having some text up front explaining this is needed.
(Whether the current text is good at explaining it is a separate matter.)

> 3 - section 1.5 renumbering implications
> 
> Could this be better relocated into section 16 (Implications 
> Elsewhere?). It semes a better fit there than in section 1

Clearly this section is a bit of a misfit. Part of what it is saying is 
that there is an issue for further study whether or the shim should 
react to a ULID becoming invalid (due to its valid lifetime expiring) by 
blowing away the context.

Should we put that in "possible extensions"?

The non-goals section already says that we are not solving survivability 
across renumbering, which is all we need to say in section one.

> 4 - section 1.7 Traffic Engineering
> 
> It may also be appropriate to include some considerations of traffic 
> engineering in section 19, and note in section 19 some of the issues 
> related to externally generated triggers for locator change and 
> externally-supplied locator preferences that would allow some form of TE 
> responses at a host.
> 
> 5 - Section 3 - Assumptions
> 
> The assumptions note the consideration of Ingress Filtering and 
> source-based path selection considerations, and appears to state the 
> same assumption twice. Perhaps an appendix should include further text 
> in the source address / site exit selection / path selection 
> considerations that are implictly assumed in this specification. It may 
> also be useful to reference some of the previous multi6 work on the 
> issues of source address section / site exit router selection.

I've rewritten this text to be more clear, and I've added a reference to 
draft-huitema-shim6-ingress-filtering.

> 6 - Section3 - Assumptions
> 
> I suspect that we assume that there are no IPv6 NATS on the path - 
> perhaps this should be explicitly stated

Yes.

> 7 - Section 4.6 - comment on Mobile IPv6
> 
> It may make sense to explicitly call out the "for further study" comment 
> in this section in section 19.

Yes.

> 8 - Section 8 - handling ICMP error messages
> 
> It may be me, but I found this section somewaht opaque. Either a diagram 
> or some further text may help in terms of understanding what transforms 
> are to be applied to the ourter ICMP packet header locators and what 
> transforms are to be appied to the inner packet segment that is in the 
> payload of the ICMP packet.

I'll add a diagram and restructure the text a bit

> 9 - section 11 - Sending ULP payloads
> 
> It is implied by the text here that if SHIM6 context reestablished use 
> of the initial locator pair as the current locators (ie. start with ULID 
> = locators, switch to new locators and then switch back to original ULID 
> = locator) then no packet transforms as specified in section 11.1 are 
> required. Should this be called out in the text?

I can certainly add that.

> As a meta consideration here, is there any logical reason to prefer the 
> initial ULIDs as locators?

The hosts have already used locators=ULIDs for the initial contact 
before the shim kicks in, and the context establishment will be done 
using those locators. Once the context is established the hosts can 
choose to switch, but such a switch isn't free; at a minimum the host 
has to verify that the peer is indeed present at the other locator by 
sending a probe packet (this is to avoid 3rd party flooding).

> 10 - section 19 Possible protocol extensions
> 
> possible additional parts here could include:
> 
> - allowing the API to trigger a locator change as well as locator 
> preference?

ok

> - allowing external triggers for locator preference and locator switch 
> (TE related)

Did you have anything more specific than the vague references to DHCP? 
This is what I currently have in my working copy:

   <t>Supporting the dynamic setting of locator preferences on a site-wide
basis, and use the Locator Preference option in the shim6 protocol to
convey these preferences to remote communicating hosts. This could mirror
the DNS SRV record's notion of priority and weight.</t>

   <t>Potentially recommend that more application protocols use DNS SRV
records to allow a site some influence on load spreading for the initial
contact (before the shim6 context establishment) as well as for traffic 
which
does not use the shim.</t>

    Erik

Delivery-date: Thu, 16 Feb 2006 20:38:34 +0000
Date: Thu, 16 Feb 2006 22:38:20 +0100
From: Olivier Bonaventure <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-03

Shinta,
>>1.7  Traffic Engineering
>>
>>   At the time of this writing it is not clear what requirements for
>>   traffic engineering make sense for the shim6 protocol, since the
>>   requirements must both result in some useful behavior as well as be
>>   implementable using a host-to-host locator agility mechanism like
>>   shim6.  What is clear that whatever they are, shim6 will not be able
>>   to provide identical capabilities to traffic engineering using BGP
>>   and Provide Independent IP addresses.
> 
> 
> It was not clear to me what the above paragraph means.
> Could someone elaborate more on this ?

With shim6, the traffic engineering capabilities will be completely 
different than with IPv4. With IPv4, ou basically mainly have BGP 
tweaking today. This is cumbersome and difficult to use efficiently.

With shim6, the selection of the source and destination locators, if 
done intelligently, can allow :
- load balancing between providers (both outgoing and incoming) in an 
enterprise network
- utilisation of many more paths than with Ipv4
- selection of the path with the lowest delay. By using a coordinate 
system as in peer-to-peer networks, it is possible to select the best 
source-destination pair from a delay viewpoint without measuring all 
possible pairs

You can find a long discussion of traffic engineering capabilities that 
are allowed by shim6 in Cédric de Launois' PhD thesis :
http://www2.info.ucl.ac.be/people/delaunoi/publications.html

Best regards,

Olivier Bonaventure

Delivery-date: Thu, 16 Feb 2006 20:31:58 +0000
Date: Thu, 16 Feb 2006 22:31:34 +0100
From: Olivier Bonaventure <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: David Meyer <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Shinta Sugimoto <[email-masked]>, [email-masked]
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

Erik,
> 
>>     Have folks seen Jason Schiller's slides from NANOG 35?
>>     Might be useful to review those for some of the issues
>>     that (some set of) providers are seeing:
>>
>>     http://www.nanog.org/mtg-0510/pdf/schiller.bof.pdf
> 
> 
> It would actually be useful for somebody to do the exercise of 
> determining which issues are fundamental because each site has multiple 
> prefixes, and what issues are specific to shim6.
> 
> For instance, even in GSE the host selects which of multiple destination 
> addresses to use, at least for the initial packet exchange.
> But in GSE the host doesn't select the source address; the border 
> routers set the source address.
> 
> I don't think we are very far away from allowing the routers to change 
> the source locator in shim6, but I don't feel we collectively 
> (IETF+NANOG etc) know how useful such a capability would be.

I'm not convinced that letting routers change the source locator in 
shim6 would be a good solution. This will add new mechanisms on the 
routers, force them to maintain some additional state and could lead to 
a NATification of IPv6.

Despite this, I have the impression that the IETF did not consider 
entreprise or ISP networks when developping shim6. The basic assumption 
has been that hosts perform all decisions related to shim6 autonomously
- host select the source and destination locators
- host check the availability of the path and switch to another one in 
case of problems

Letting hosts select paths in multihomed scenarios where a enduser is 
attached to both ADSL and CATV networks is useful. However, if the host 
belongs to an entreprise network, then the managers of the entreprise 
network will probably want to influence the selection of the source and 
destination locators. One possibility to do this would be to tune the 
DNS servers (assuming the hosts perform DNS requests before sending 
data) or define a protocol, used in the entreprise network to perform 
the address selection on behalf of the endsystem. Such a protocol was 
proposed a few years ago :

http://www2.info.ucl.ac.be/people/delaunoi/ietf/draft-de-launois-multi6-naros-00.txt

Letting hosts detect failures is a nice approach in the ADSL+CATV 
environment. In an entreprise network, the border router could receive 
information about the failure (e.g. reception of BGP withdraw) and 
inform the endsystems in the network.

I think that shim6 will have to consider issues that arise when 
thousands of multihomed hosts are in the same entreprise or campus network.

Best regards

Olivier
-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

Delivery-date: Thu, 16 Feb 2006 20:03:39 +0000
Date: Thu, 16 Feb 2006 15:02:22 -0500 (EST)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-03
To: Erik Nordmark <[email-masked]>
Cc: Shinta Sugimoto <[email-masked]>, [email-masked]

On Thu, 16 Feb 2006, Erik Nordmark wrote:

> Yes, but that isn't a property of "host centric" - it is a property of
> any scheme that would have multiple prefixes for a multihomed site (even
> for instance if the multiple prefixes are handled by some
> routers/proxies at the site boundaries).
> You end up with multiple addresses in the DNS so that the initial
> contact can be robust against a single failure.

The problem here is not not the multiple addresses, but rather a partial
ID / locator split.  As long as DNS contains information about both the
identity of the host and the location of the host then the ID and the
locator are not completely split.  This creates the problem of sifting
through DNS, and making the solution non-useful for short lived
sessions.  Also, this problem is what is creating the push for provider
independent (PI) IPv6 space to avoid "provider lock-in".

Imagine instead DNS only has knowledge of the identity, say the host
address, local subnetting and a way to uniquely identify the site.  The
source host builds a packet and kicks it to the network without the
locator information.  The network needs some mechinism to map the site
identity to one or more locators.  In this model the source host,
destination host, and DNS system don't care about location.  This is left
up to some protocol in the network.  On ingress this could be easy for the
source, just pre-pend your routing locator.  For the destination there
would need to be some mapping of site ID to one or more locators.  The
network could pick the most convient locator for the destination.

This same site ID to locator mapping protocol could be used by transit
ASes to rewrite the destination locator information and forward the
packet towards the destination at an alternate location.  Transit ASes
that don't wich to perform TE can simply forward the packet and do not
require the added site/locator state.

I'm not sure this scales any better than de-aggregation as all ingress
routers and any transit routers that want TE will need state to map one or
more locators to every site.

___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, 16 Feb 2006, Erik Nordmark wrote:

> Date: Thu, 16 Feb 2006 11:06:08 -0800
> From: Erik Nordmark <[email-masked]>
> To: Shinta Sugimoto <[email-masked]>
> Cc: [email-masked]
> Subject: Re: comments on draft-ietf-shim6-proto-03
> 
> Shinta Sugimoto wrote:
> 
> >> Inherent in a scalable multihoming mechanism that separates locators 
> >> from identifiers is that each host ends up with multiple locators.
> >> This means that at least for initial contact, it is the remote peer that 
> >> needs to select which peer locator to try first. In the case of shim6 
> >> this is performed by applying RFC 3484 address selection.
> >>
> >> This is quite different than the common case of IPv4 multihoming where 
> >> the site has a single IP address prefix, since in that case the peer 
> >> performs no destination address selection.
> >>
> >> Thus in "single prefix multihoming" the site, and in many cases its 
> >> upstream ISPs, can use BGP to exert some control of the ingress used to 
> >> reach the site. This capability can't easily be recreated in "multiple 
> >> prefix multihoming" such as shim6.
> > 
> > I am not sure if I understand the above texts correctly, but my
> > interpretation of above texts is that the host centric approach
> > (or the concept of id-locator split) of SHIM6 in which a host should
> > deal with multiple locators at a time has implications on source &
> > destination address selection to be done by the end nodes.
> 
> Yes, but that isn't a property of "host centric" - it is a property of 
> any scheme that would have multiple prefixes for a multihomed site (even 
> for instance if the multiple prefixes are handled by some 
> routers/proxies at the site boundaries).
> You end up with multiple addresses in the DNS so that the initial 
> contact can be robust against a single failure.
> 
> > In contrasts, under single prefix multihoming environment, there is
> > no such requirements for the end nodes but routers inside the network
> > are required to somehow manage routing information so that the IP
> > packets destined to the node which has IP address derived from the
> > multihomed prefix.  But,, I wonder how this relates to Traffic
> > Engineering.  I should admit that I don't have deep insight into
> > Traffic Engineering, though.
> 
> It does have implications on traffic engineering.
> 
> But any scalable multihoming approach needs to have multiple prefixes 
> for a site in order to avoid a route in the Default-free zone for every 
> multihomed site. So as a first order approximation, this impact on TE is 
> fundamental to the problem we are trying to solve and not specific to shim6.
> 
> There are differences on how a site administrator or an ISP can 
> influence the locators that are used, for instance Mike O'Dell's 
> original GSE proposal has locator rewriting as a way for routers to 
> influence the choice *after* the first packets have been exchanged. I 
> don't know if such a capability would be useful for shim6.
> 
> 
> >>>>    o  Some heuristic on A or B (or both) determine that it might make
> >>>>       sense to make this communication robust against locator failures.
> >>>>       For instance, this heuristic might be that more than 50 packets
> >>> s/heuristic/heuristics/
> >> Singular form is without the 's' AFAIK.
> > 
> > I am not a native English speaker but my dictionary says that "heuristic"
> > is adjective and "heuristics" is noun (uncountable).
> 
> Neither am I. But the dictionary doesn't seem to match common computer 
> science usage. "a heuristic" is used in 
> http://en.wikipedia.org/wiki/Heuristic_%28computer_science%29
> 
>     Erik
> 
> 
> 

Delivery-date: Thu, 16 Feb 2006 19:26:59 +0000
Date: Thu, 16 Feb 2006 11:26:09 -0800
From: Erik Nordmark <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Spencer Dawkins <[email-masked]>, [email-masked]
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

Geoff Huston wrote:
> In response to your query (and Erik can correct me if I'm wrong) It is 
> my understanding in the specification that whenever the ULID pair is 
> used as the locator pair then the SHIM6 extension header (the context 
> value) is omitted from the packet. This allies to the initial contact 
> pahse, and also in any subsequent time when the SHIM selects the ULID 
> pair as the current locator pair.

Correct. But folks have also suggested that we should allow the shim6 
extension header all the time i.e., even if the receiver doesn't have to 
rewrite the locators. I don't see any harm in allowing this for folks 
that want their packets to be bigger...

> i.e. it is my understanding that the packet header is simply an implicit 
> "please perform an address substitution" instruction to the other end, 
> and the locator pair plus the context value identifies the particular 
> substitution to a ULID pair that the remote end should perform. If the 
> locators are the ULID then no substitution is necessary, and no 
> extension header is necessary.
> 
> At least thats the way I interpret the specification, and I was 
> wondering if this should be explicitly stated in the spec.

If we allow the above, it is really "please lookup the context state and 
check if you need to replace the locators", but since replacing the 
locator pair with the identical locator pair can be still viewed as a 
replacement, that's just a detail.

Any ideas where such text would best belong in the specification?

    Erik

Delivery-date: Thu, 16 Feb 2006 19:25:42 +0000
Date: Thu, 16 Feb 2006 11:25:23 -0800
From: David Meyer <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, Shinta Sugimoto <[email-masked]>, [email-masked]
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2006 at 11:16:15AM -0800, Erik Nordmark wrote:
> David Meyer wrote:
>=20
> >	Have folks seen Jason Schiller's slides from NANOG 35?
> >	Might be useful to review those for some of the issues
> >	that (some set of) providers are seeing:
> >
> >	http://www.nanog.org/mtg-0510/pdf/schiller.bof.pdf
>=20
> It would actually be useful for somebody to do the exercise of=20
> determining which issues are fundamental because each site has multiple=
=20
> prefixes, and what issues are specific to shim6.
>=20
> For instance, even in GSE the host selects which of multiple destination=
=20
> addresses to use, at least for the initial packet exchange.
> But in GSE the host doesn't select the source address; the border=20
> routers set the source address.
>=20
> I don't think we are very far away from allowing the routers to change=20
> the source locator in shim6, but I don't feel we collectively=20
> (IETF+NANOG etc) know how useful such a capability would be.

	There is also the (important, IMO) question as to whether
	IPv4-style TE can be made to scale in any event,
	independent of the IP version or the existence (or
	non-existence) of shim6.

	Dave

=09

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline

--wRRV7LY7NUeQGEoC--

Delivery-date: Thu, 16 Feb 2006 19:17:18 +0000
Date: Thu, 16 Feb 2006 11:16:15 -0800
From: Erik Nordmark <[email-masked]>
To: David Meyer <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Shinta Sugimoto <[email-masked]>, [email-masked]
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

David Meyer wrote:

> 	Have folks seen Jason Schiller's slides from NANOG 35?
> 	Might be useful to review those for some of the issues
> 	that (some set of) providers are seeing:
> 
> 	http://www.nanog.org/mtg-0510/pdf/schiller.bof.pdf

It would actually be useful for somebody to do the exercise of 
determining which issues are fundamental because each site has multiple 
prefixes, and what issues are specific to shim6.

For instance, even in GSE the host selects which of multiple destination 
addresses to use, at least for the initial packet exchange.
But in GSE the host doesn't select the source address; the border 
routers set the source address.

I don't think we are very far away from allowing the routers to change 
the source locator in shim6, but I don't feel we collectively 
(IETF+NANOG etc) know how useful such a capability would be.

    Erik

Delivery-date: Thu, 16 Feb 2006 19:08:03 +0000
Date: Thu, 16 Feb 2006 11:06:53 -0800
From: Erik Nordmark <[email-masked]>
To: Joe Abley <[email-masked]>
CC: Shinta Sugimoto <[email-masked]>, [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-03

Joe Abley wrote:
> 
> On 14-Feb-2006, at 19:36, Erik Nordmark wrote:
> 
>>> I am not sure if there is semantic difference between "load balancing"
>>> and "load spreading", but the former sounds more familiar to me.
>>
>> I'll switch back to "balancing" since that is more common.
> 
> In draft-ietf-grow-anycast, we found that people read overtones of 
> "equal sharing of traffic" into the phrase "load balancing". In cases 
> where we didn't mean to imply an equal sharing of traffic, we used the 
> phrase "load sharing".
> 
> The reviewing audience of that draft seemed to support this distinction, 
> for what that's worth.

OK. So I'll keep "spreading" and add some explanatory text.

    Erik

Delivery-date: Thu, 16 Feb 2006 19:07:05 +0000
Date: Thu, 16 Feb 2006 11:06:08 -0800
From: Erik Nordmark <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-03

Shinta Sugimoto wrote:

>> Inherent in a scalable multihoming mechanism that separates locators 
>> from identifiers is that each host ends up with multiple locators.
>> This means that at least for initial contact, it is the remote peer that 
>> needs to select which peer locator to try first. In the case of shim6 
>> this is performed by applying RFC 3484 address selection.
>>
>> This is quite different than the common case of IPv4 multihoming where 
>> the site has a single IP address prefix, since in that case the peer 
>> performs no destination address selection.
>>
>> Thus in "single prefix multihoming" the site, and in many cases its 
>> upstream ISPs, can use BGP to exert some control of the ingress used to 
>> reach the site. This capability can't easily be recreated in "multiple 
>> prefix multihoming" such as shim6.
> 
> I am not sure if I understand the above texts correctly, but my
> interpretation of above texts is that the host centric approach
> (or the concept of id-locator split) of SHIM6 in which a host should
> deal with multiple locators at a time has implications on source &
> destination address selection to be done by the end nodes.

Yes, but that isn't a property of "host centric" - it is a property of 
any scheme that would have multiple prefixes for a multihomed site (even 
for instance if the multiple prefixes are handled by some 
routers/proxies at the site boundaries).
You end up with multiple addresses in the DNS so that the initial 
contact can be robust against a single failure.

> In contrasts, under single prefix multihoming environment, there is
> no such requirements for the end nodes but routers inside the network
> are required to somehow manage routing information so that the IP
> packets destined to the node which has IP address derived from the
> multihomed prefix.  But,, I wonder how this relates to Traffic
> Engineering.  I should admit that I don't have deep insight into
> Traffic Engineering, though.

It does have implications on traffic engineering.

But any scalable multihoming approach needs to have multiple prefixes 
for a site in order to avoid a route in the Default-free zone for every 
multihomed site. So as a first order approximation, this impact on TE is 
fundamental to the problem we are trying to solve and not specific to shim6.

There are differences on how a site administrator or an ISP can 
influence the locators that are used, for instance Mike O'Dell's 
original GSE proposal has locator rewriting as a way for routers to 
influence the choice *after* the first packets have been exchanged. I 
don't know if such a capability would be useful for shim6.

>>>>    o  Some heuristic on A or B (or both) determine that it might make
>>>>       sense to make this communication robust against locator failures.
>>>>       For instance, this heuristic might be that more than 50 packets
>>> s/heuristic/heuristics/
>> Singular form is without the 's' AFAIK.
> 
> I am not a native English speaker but my dictionary says that "heuristic"
> is adjective and "heuristics" is noun (uncountable).

Neither am I. But the dictionary doesn't seem to match common computer 
science usage. "a heuristic" is used in 
http://en.wikipedia.org/wiki/Heuristic_%28computer_science%29

    Erik

Delivery-date: Thu, 16 Feb 2006 18:29:24 +0000
Date: Thu, 16 Feb 2006 10:28:00 -0800
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Subject: [Fwd: Review comments on draft-ietf-shim6-proto-03.txt]

Geoff has sent me many very good editorial clarifications which I've 
applied to the draft.

But there was one where I didn't quite agree that it was an editorial 
change so it makes sense to discuss it on the list.

The text and Geoff's suggested change were:

1.2  Non-Goals

    The assumption is that the problem we are trying to solve is site
    multihoming, with the ability to have the set of site locator
    prefixes change over time due to site renumbering.  Further, we
    assume that such changes to the set of locator prefixes can be
    relatively slow and managed; slow enough to allow updates to the DNS
    to propagate.  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.  However, it
|   might turn out that the shim6 protocol can be a useful component,
|   e.g., for route optimization in the context of host mobility.

replace with
-------

be applicable to host mobility, although this is an area for further study.

---

While the shim6 WG hasn't been chartered to solve the mobility problem, 
the above text in the draft states (and I think accurately so) that 
shim6 can be useful for route optimization when shim6 is coupled with 
host mobility.

Thus shim6 has some potential applicability to mobility.

Hence I think Geoff's suggestion is making a too strong statement, even 
if we do not today have consensus around how mobility+multihoming will 
evolve.

Comments?

     Erik

Delivery-date: Thu, 16 Feb 2006 17:24:18 +0000
Cc: Shinta Sugimoto <[email-masked]>, [email-masked], Erik Nordmark <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Thu, 16 Feb 2006 12:24:09 -0500
To: marcelo bagnulo braun <[email-masked]>

On 16-Feb-2006, at 09:39, marcelo bagnulo braun wrote:

> Well, i would say that Traffic engineering is about how to  
> influence routing (i.e. path selection) based on policy considerations
>
> So, as Erik points out above, in the IPv4-BGP-style multihoming, TE  
> and path selection is performed by changing BGP knobs when  
> announcing routes. In particular, it is the guy that is configuring  
> the BGP router the one that will try to influence the path  
> selection (using stuff like AS path prepending, more specific  
> routes, MED attributes, communities...). Moreover, because each  
> direction of the packet flow is influenced by the route  
> announcement, TE is likely to be set per direction.
>
> OTOH, in the SHIM model, each egress path of the multihomed site is  
> associated with a given prefix. This basically means that selecting  
> a prefix of a multihomed host, implies the selection of the path of  
> the multihomed site used to reach that host. This selection is  
> performed by the host, so it is up to the host admin to actually  
> select the path.

I think it's pertinent to note that peer-to-peer traffic in IPv4 is  
frequently balanced dynamically by end hosts today (through choice of  
peer).

I hear about several user-heavy networks who see over 60% of their  
traffic from bittorrent, for example. Although I have no science to  
promote this as widespread truth, I have yet to find an operator who  
measures such things who disagree with me when I mention such a figure.

If we can consider a future in which peer-to-peer traffic increases,  
relative to other applications, and in which locality-sensitive peer- 
to-peer protocols become more common, then TE looks like it's  
naturally shifting to the end hosts anyway; ISPs are left playing an  
increasingly futile game of whack-a-mole.

Crippling a multi-homing solution in the interests of preserving a  
capability which is increasingly absent does not seem sensible.

Joe

Delivery-date: Thu, 16 Feb 2006 17:23:38 +0000
Date: Thu, 16 Feb 2006 09:22:51 -0800
From: David Meyer <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: Shinta Sugimoto <[email-masked]>, [email-masked], Erik Nordmark <[email-masked]>
Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

--Dxnq1zWXvFF0Q93v
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2006 at 03:39:07PM +0100, marcelo bagnulo braun wrote:
> Hi Shinta,
>=20
> El 15/02/2006, a las 6:25, Shinta Sugimoto escribi=F3:
> >
> >>>>1.7  Traffic Engineering
> >>>>
> >>>>   At the time of this writing it is not clear what requirements for
> >>>>   traffic engineering make sense for the shim6 protocol, since the
> >>>>   requirements must both result in some useful behavior as well as=
=20
> >>>>be
> >>>>   implementable using a host-to-host locator agility mechanism like
> >>>>   shim6.  What is clear that whatever they are, shim6 will not be=20
> >>>>able
> >>>>   to provide identical capabilities to traffic engineering using=20
> >>>>BGP
> >>>>   and Provide Independent IP addresses.
> >>>
> >>>It was not clear to me what the above paragraph means.
> >>>Could someone elaborate more on this ?
> >>
> >>Let me know if this is more clear:
> >>
> >>Inherent in a scalable multihoming mechanism that separates locators
> >>from identifiers is that each host ends up with multiple locators.
> >>This means that at least for initial contact, it is the remote peer=20
> >>that
> >>needs to select which peer locator to try first. In the case of shim6
> >>this is performed by applying RFC 3484 address selection.
> >>
> >>This is quite different than the common case of IPv4 multihoming where
> >>the site has a single IP address prefix, since in that case the peer
> >>performs no destination address selection.
> >>
> >>Thus in "single prefix multihoming" the site, and in many cases its
> >>upstream ISPs, can use BGP to exert some control of the ingress used=20
> >>to
> >>reach the site. This capability can't easily be recreated in "multiple
> >>prefix multihoming" such as shim6.
> >
> >I am not sure if I understand the above texts correctly, but my
> >interpretation of above texts is that the host centric approach
> >(or the concept of id-locator split) of SHIM6 in which a host should
> >deal with multiple locators at a time has implications on source &
> >destination address selection to be done by the end nodes.
> >In contrasts, under single prefix multihoming environment, there is
> >no such requirements for the end nodes but routers inside the network
> >are required to somehow manage routing information so that the IP
> >packets destined to the node which has IP address derived from the
> >multihomed prefix.  But,, I wonder how this relates to Traffic
> >Engineering.  I should admit that I don't have deep insight into
> >Traffic Engineering, though.
> >
>=20
> Well, i would say that Traffic engineering is about how to influence=20
> routing (i.e. path selection) based on policy considerations
>=20
> So, as Erik points out above, in the IPv4-BGP-style multihoming, TE and=
=20
> path selection is performed by changing BGP knobs when announcing=20
> routes. In particular, it is the guy that is configuring the BGP router=
=20
> the one that will try to influence the path selection (using stuff like=
=20
> AS path prepending, more specific routes, MED attributes,=20
> communities...). Moreover, because each direction of the packet flow is=
=20
> influenced by the route announcement, TE is likely to be set per=20
> direction.

	Yep.

> OTOH, in the SHIM model, each egress path of the multihomed site is=20
> associated with a given prefix. This basically means that selecting a=20
> prefix of a multihomed host, implies the selection of the path of the=20
> multihomed site used to reach that host. This selection is performed by=
=20
> the host, so it is up to the host admin to actually select the path.

	Also true.

> So, in BGP-IPv4-PI style multihoming, the elements involved in TE is=20
> router configuration, BGP attributes and Network admin of the=20
> multihomed site.
> In SHIM6-multiple PA style multihoming, the elements involved is the=20
> host itself, address selection techniques and policies, and even DNS=20
> information published and the host admin.

	Again, true.

> Another difference is that in BGP style multihoming, the traffic is=20
> influenced in a per direction basis i.e. all the traffic flowing in one=
=20
> direction is affected by a given set of knobs. OTOH, in the shim model,=
=20
> the traffic is influenced by the endpoint that initiates the=20
> communication, since it is the one that performs address selection in=20
> the first place, so, it doesn't matter so much in which direction the=20
> traffic is flowing but rather which endpoint had initiated the=20
> communication.
>=20
	Have folks seen Jason Schiller's slides from NANOG 35?
	Might be useful to review those for some of the issues
	that (some set of) providers are seeing:

	http://www.nanog.org/mtg-0510/pdf/schiller.bof.pdf

	Dave

--Dxnq1zWXvFF0Q93v
Content-Type: application/pgp-signature
Content-Disposition: inline

--Dxnq1zWXvFF0Q93v--

Delivery-date: Thu, 16 Feb 2006 14:40:19 +0000
Cc: [email-masked], Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Date: Thu, 16 Feb 2006 15:39:07 +0100
To: Shinta Sugimoto <[email-masked]>

Hi Shinta,

El 15/02/2006, a las 6:25, Shinta Sugimoto escribi=F3:
>
>>>> 1.7  Traffic Engineering
>>>>
>>>>    At the time of this writing it is not clear what requirements =
for
>>>>    traffic engineering make sense for the shim6 protocol, since the
>>>>    requirements must both result in some useful behavior as well as=20=

>>>> be
>>>>    implementable using a host-to-host locator agility mechanism =
like
>>>>    shim6.  What is clear that whatever they are, shim6 will not be=20=

>>>> able
>>>>    to provide identical capabilities to traffic engineering using=20=

>>>> BGP
>>>>    and Provide Independent IP addresses.
>>>
>>> It was not clear to me what the above paragraph means.
>>> Could someone elaborate more on this ?
>>
>> Let me know if this is more clear:
>>
>> Inherent in a scalable multihoming mechanism that separates locators
>> from identifiers is that each host ends up with multiple locators.
>> This means that at least for initial contact, it is the remote peer=20=

>> that
>> needs to select which peer locator to try first. In the case of shim6
>> this is performed by applying RFC 3484 address selection.
>>
>> This is quite different than the common case of IPv4 multihoming =
where
>> the site has a single IP address prefix, since in that case the peer
>> performs no destination address selection.
>>
>> Thus in "single prefix multihoming" the site, and in many cases its
>> upstream ISPs, can use BGP to exert some control of the ingress used=20=

>> to
>> reach the site. This capability can't easily be recreated in =
"multiple
>> prefix multihoming" such as shim6.
>
> I am not sure if I understand the above texts correctly, but my
> interpretation of above texts is that the host centric approach
> (or the concept of id-locator split) of SHIM6 in which a host should
> deal with multiple locators at a time has implications on source &
> destination address selection to be done by the end nodes.
> In contrasts, under single prefix multihoming environment, there is
> no such requirements for the end nodes but routers inside the network
> are required to somehow manage routing information so that the IP
> packets destined to the node which has IP address derived from the
> multihomed prefix.  But,, I wonder how this relates to Traffic
> Engineering.  I should admit that I don't have deep insight into
> Traffic Engineering, though.
>

Well, i would say that Traffic engineering is about how to influence=20
routing (i.e. path selection) based on policy considerations

So, as Erik points out above, in the IPv4-BGP-style multihoming, TE and=20=

path selection is performed by changing BGP knobs when announcing=20
routes. In particular, it is the guy that is configuring the BGP router=20=

the one that will try to influence the path selection (using stuff like=20=

AS path prepending, more specific routes, MED attributes,=20
communities...). Moreover, because each direction of the packet flow is=20=

influenced by the route announcement, TE is likely to be set per=20
direction.
OTOH, in the SHIM model, each egress path of the multihomed site is=20
associated with a given prefix. This basically means that selecting a=20
prefix of a multihomed host, implies the selection of the path of the=20
multihomed site used to reach that host. This selection is performed by=20=

the host, so it is up to the host admin to actually select the path.

So, in BGP-IPv4-PI style multihoming, the elements involved in TE is=20
router configuration, BGP attributes and Network admin of the=20
multihomed site.
In SHIM6-multiple PA style multihoming, the elements involved is the=20
host itself, address selection techniques and policies, and even DNS=20
information published and the host admin.

Another difference is that in BGP style multihoming, the traffic is=20
influenced in a per direction basis i.e. all the traffic flowing in one=20=

direction is affected by a given set of knobs. OTOH, in the shim model,=20=

the traffic is influenced by the endpoint that initiates the=20
communication, since it is the one that performs address selection in=20
the first place, so, it doesn't matter so much in which direction the=20
traffic is flowing but rather which endpoint had initiated the=20
communication.

Hope this helps a bit,

regards, marcelo

Delivery-date: Wed, 15 Feb 2006 17:03:47 +0000
Cc: Shinta Sugimoto <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-03
Date: Wed, 15 Feb 2006 12:02:51 -0500
To: Erik Nordmark <[email-masked]>

On 14-Feb-2006, at 19:36, Erik Nordmark wrote:

>> I am not sure if there is semantic difference between "load  
>> balancing"
>> and "load spreading", but the former sounds more familiar to me.
>
> I'll switch back to "balancing" since that is more common.

In draft-ietf-grow-anycast, we found that people read overtones of  
"equal sharing of traffic" into the phrase "load balancing". In cases  
where we didn't mean to imply an equal sharing of traffic, we used  
the phrase "load sharing".

The reviewing audience of that draft seemed to support this  
distinction, for what that's worth.

Joe

Delivery-date: Wed, 15 Feb 2006 05:26:10 +0000
Date: Wed, 15 Feb 2006 14:25:02 +0900
From: Shinta Sugimoto <[email-masked]>
To: Erik Nordmark <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-03
Cc: [email-masked]

Hello Erik,

Thank you for your feedback.  Please find my comments inline:

On Tue, 14 Feb 2006 16:36:02 -0800
Erik Nordmark <[email-masked]> wrote:

> Shinta Sugimoto wrote:
> > Hello,
> > 
> > Let me post my comments on draft-ietf-shim6-proto-03.  I have not read
> > the whole document yet, but here are my comments/questions from Section
> > 1 to Section 14.  Some are editorial, some are technical.  I will
> > continue to read rest of the document and send more comments later.
> 
> Thanks for your comments and sorry for the tardy response.
> I've used your comments as an indication where we can make the document 
> more clear, and I've applied your typo fixes.
> 
> >>    o  No extra roundtrip for setup; deferred setup.
> > 
> > I am not sure what does the above (fourth) bullet mean.  Does
> > "deferred setup" mean context establishment follows the IP transaction
> > based on the ULID pair ?
> 
> What it means (and I'll clarify the document) is that we don't require 
> some extra shim6 handshake before TCP/UDP/etc packets can flow. Instead 
> normal TCP/UDP/whatever packets can flow and later and in parallel the 
> shim6 context can be setup.

Ok, I see.  I agree that it (deferred setup) is important and should be
one of the goals.

> > I am not sure if there is semantic difference between "load balancing"
> > and "load spreading", but the former sounds more familiar to me.
> 
> I'll switch back to "balancing" since that is more common.
> 
> One can make a distinction between "balance" as a way to enforce a 
> particular split (e.g., a 50/50 balance), and the techniques in shim6 to 
> have different connections (from the same or different hosts) pick at 
> random between multiple destination addresses doesn't ensure "balance" - 
> a single connection might represent the bulk of the traffic. Hence I 
> used "spreading" for this for loose concept.

Ok.

> 
> > Section 1.4 talks about relation to IP Multicast as above.  While I
> > agree that applying SHIM6 to the sender of IP Multicast does not seem
> > reasonable (in a sense that it requires sender to establish context
> > with all the receivers, which is unrealistic) it might be worth taking
> > a look at applicability of SHIM6 to the receiver node.  As typical
> > scenario of IP multicast would be that the sender node is stationary
> > and receiver spreads in the network. It is more likely that receiver
> > changes its locator frequently than sender.
> 
> The approach doesn't prevent the receiver of multicast to change its 
> locators, since the receiver is not explicitly identified; the 
> destination address is a multicast address and not the unicast locator 
> of the receiver.

You are right.  I think I misunderstood the issue.  In IP multicast,
locator change of the receiver is invisible to the sender.  Current
texts in Section 1.4 seem just fine.

> > In general, I agree with what is stated in Section 1.5 about renumbering
> > implications.  Particularly, we should consider how a host treats the
> > ULID which becomes unavailable.  In such case, at least the ULID should
> > be removed from the physical interface and marked as
> > "still-in-use-but-to-be-soon-removed."  The active connection which is
> > based on the ULID may continue but the ULID should not be used for new
> > connections.
> 
> I see the text is missing the introductory material which explains that 
> the "locator role" of the IPv6 address can be renumbered away; it is the 
> "ULID role" which raises the issue.

Exactly.

> I'll start the section as:
> <t>As stated above, this approach does not try to make communication
> survive renumbering in the general case.</t>
> 
> <t>When a host is renumbered, the effect is that one or more locators become
> invalid, and zero or more locators are added to the host's network 
> interface.
> This means that the set of locators that is used in the shim will change,
> which the shim can handle as long as not all the original locators become
> invalid at the same time.</t>
> 
> <t>But IP addresses are also used as ULID, and making the communication
> survive locators becoming invalid can potentially cause some confusion 
> at the
> upper layers. <old text>

Ok, I think it's better to add above texts.

> > IMHO, it would be good to mention that IP addresses to be specified in
> > selector information of security policy should be ULID (if locator agility
> > is required).  I expect that even IKEv1/IKEv2 would also be possible to
> > run over SHIM6, for instance.
> 
> I'll add something.

Ok.

> >> 1.7  Traffic Engineering
> >>
> >>    At the time of this writing it is not clear what requirements for
> >>    traffic engineering make sense for the shim6 protocol, since the
> >>    requirements must both result in some useful behavior as well as be
> >>    implementable using a host-to-host locator agility mechanism like
> >>    shim6.  What is clear that whatever they are, shim6 will not be able
> >>    to provide identical capabilities to traffic engineering using BGP
> >>    and Provide Independent IP addresses.
> > 
> > It was not clear to me what the above paragraph means.
> > Could someone elaborate more on this ?
> 
> Let me know if this is more clear:
> 
> Inherent in a scalable multihoming mechanism that separates locators 
> from identifiers is that each host ends up with multiple locators.
> This means that at least for initial contact, it is the remote peer that 
> needs to select which peer locator to try first. In the case of shim6 
> this is performed by applying RFC 3484 address selection.
> 
> This is quite different than the common case of IPv4 multihoming where 
> the site has a single IP address prefix, since in that case the peer 
> performs no destination address selection.
> 
> Thus in "single prefix multihoming" the site, and in many cases its 
> upstream ISPs, can use BGP to exert some control of the ingress used to 
> reach the site. This capability can't easily be recreated in "multiple 
> prefix multihoming" such as shim6.

I am not sure if I understand the above texts correctly, but my
interpretation of above texts is that the host centric approach
(or the concept of id-locator split) of SHIM6 in which a host should
deal with multiple locators at a time has implications on source &
destination address selection to be done by the end nodes.
In contrasts, under single prefix multihoming environment, there is
no such requirements for the end nodes but routers inside the network
are required to somehow manage routing information so that the IP
packets destined to the node which has IP address derived from the
multihomed prefix.  But,, I wonder how this relates to Traffic
Engineering.  I should admit that I don't have deep insight into
Traffic Engineering, though.

> 
> > ...[snip]...
> >>    Current locator pair Each end of the context has a current locator
> >>                        pair which is used to send packets to be peer.
> >>                        The two ends might use different current locator
> >>                        pairs though.
> > 
> > Is this true ?  My understanding is that the two ends (I and R) must
> > have exactly the same current locator pair for the bi-directional
> > context.  Otherwise, I guess receiver node maybe confused when it
> > tries to demux the receiving packet.  Could someone help me clarify ?
> 
> They can be different. The locator *sets* known by the two ends will be 
> the same, but each end can independently decide to switch over to use a 
> different locator pair for the packets it is sending.
> 
> The receiver uses the set of locator pairs for the demux in combination 
> with the context tag. For the data packets the 47-bit context tag is all 
> the receiver needs to check for demuxing.

I see.

> 
> >>    Forked Instance Identifier (FII) In order to handle contxt forking,
> >>                        a context is identified by a ULID-pair and a
> >>                        forked context identifier.  The default context
> >>                        has a FII of zero.
> > 
> > Is any specific data type defined for FII (eg. unsigned int) ?
> 
> Presumably a future ULP-to-SHIM6 API document will define the exact data 
> type. Presumably one doesn't have to support a lot of forked contexts, 
> thus a 32-bit FII would certainly be sufficient.

Ok.

> 
> >>    o  Some heuristic on A or B (or both) determine that it might make
> >>       sense to make this communication robust against locator failures.
> >>       For instance, this heuristic might be that more than 50 packets
> > 
> > s/heuristic/heuristics/
> 
> Singular form is without the 's' AFAIK.

I am not a native English speaker but my dictionary says that "heuristic"
is adjective and "heuristics" is noun (uncountable).

> 
> >>    o  In addition to failures detected based on end-to-end observations,
> >>       one endpoint might be know for certain that one or more of its
> > 
> > s/know/known/
> 
> s/be// is even better

Ok.

> 
> > I think this is an interesting issue.  Assuming that node A sends packet
> > to B traversing the tunneling agent C; if the packet from node A happens
> > to be tunneled by C to B, we have several choices how to apply SHIM6.
> > I think the consequence would be depending on which entities establish
> > context.  Let me expand it a little bit more.
> > 
> > a) If A and B establish SHIM6 context, a packet received by node B would
> > look like:
> > 
> > 	[Outer IP header]
> > 		src=C, dst=B
> > 	[Inner IP header]
> > 		src=L(A), dst=L(B) 
> > 	[Shim6 Extension header]
> > 	...(Payload)...
> > 
> > b) If C and B establish SHIM6 context, a packet received by node B would
> > look like:
> > 
> > 	[Outer IP header]
> > 		src=L(C), dst=L(B)
> > 	[Shim6 Extension header]
> > 	[Inner IP header]
> > 		src=A, dst=B 
> > 	...(Payload)...
> 
> Yes, those options do exist.
> b) is basically applying a shim to the tunnel itself, and perhaps there 
> will be some use for this in some cases.

I agree.

> >>    In most cases IP-in-IP tunnels are used as a routing technique, thus
> >>    it makes sense to apply them on the locators which means that the
> >>    sender would insert the shim6 header after any IP-in-IP
> >>    encapsulation; this is what occurs naturally when routers apply IP-
> >>    in-IP encapsulation.
> > 
> > I would like to have clarification which case a) or b) does the above
> > sentence means.  IMHO, both a) and b) should be possible.  b) is slightly
> > complex in a sense that SHIM6 packet processing takes place after
> > forwarding is done (at the router, namely node C in this case) at the
> > IP layer however it remains logical.  Any comments ?
> 
> For Mobile IPv6 tunnels (which was on my mind when writing the above) it 
> makes sense to apply the shim above the tunneling layer.
> So the text does refer to case a), even if that's hard to see from 
> reading it.

Ok.

> 
> I'll use your text to more clearly state the options.
> 
> 
> >> 7.4  Context confusion
> >>
> > 
> > ...[snip]...
> > 
> >>    The requirement is that the old context which used the context tag
> >>    MUST be removed; it can no longer be used to send packets.
> > 
> > Yes, but we should note one thing: Even if a node receives I1 message
> > with a duplicated context tag proposed by the other end, receiver node
> > should not delete old context until the context establishment is
> > successfully done.
> 
> Yes, I think that text exists in the detailed descriptions in 7.7 etc, 
> but it makes sense to add it in 7.4 as well.

Ok.

> >>
> >>    o  If the state is ESTABLISHED, it means that the Initiator has lost
> >>       the context information for this context and it is trying to
> >>       establish a new one.  In this case, the host MUST update the
> >>       existing context and replace CT(peer) with the Initiator Context
> >>       Tag included in the I1 message and then reply with an R2 message,
> >>       including the associated state information.  In this case the host
> >>       MUST look for any other (old) context with a matching CT(peer) as
> >>       specified in Section 7.12.  This completes the I1 processing, with
> >>       the context state being unchanged.
> > 
> > Same as my previous comment, but I believe the above rule is not good
> > because it may allow malicious node to send false I1 message (by possibly
> > spoofing the source IP address) and delete corresponding context.
> 
> Correct. I think Marcelo had found this, but not send it to the mailing 
> list. Basically we shouldn't update CT(peer) until after a 3-way handshake.

I agree.

> >>    If at least one of the above verification fails, then it silently
> >>    discard the packet and it has completed the I2 processing.
> > 
> > IMHO, it is better to rephrase above paragraph as below:
> > "If any of the above verification fails, the host MUST silently discard
> > the packet and complete the I2 processing."
> 
> Yes, that's better.
> 
> >> 7.12  Match for Context Confusion
> >>
> >>    When the host receives an I2, I2bis, or R2 it MUST look for a
> > 
> > similar (might be same) comment again, but I believe the verification
> > discussed here should be applied for I2bis and R2 message.  For I2
> > message, if the CT looks different from the one appeared on I1 message,
> > the I2 message should be considered invalid.
> 
> I don't understand the case. There is no state created on the reception 
> of the I1. But the initiator can't change the CT because it is included 
> in the verifier option computation. So what case do you think is 
> problematic?

Sorry, I think I misunderstood.  After I reread the descriptions about
context confusion, I understood that the descriptions in Section 7.12
are correct.  In other words, verification for context confusion should
be performed whenever CT is proposed by the peer (after 3-way handshake).
Understood.

> 
> 
> > I understand it is necessary to restore the original packet included in
> > the ICMP error message.  Besides, I wonder if there is any kind of ICMP
> > error message to which SHIM6 protocol stack should react (e.g. changing
> > state of corresponding context).  For instance, if the node receives
> > host unreach, should the corresponding host pair context be torn down ?
> 
> The draft-ietf-shim6-failure-detection-03.txt document treats those as 
> hints. In any case, they are not used to fail the shim6 context/ULID but 
> a hint that the destination locator is unreachable.

I see.  With regard to the reachability failure which happens to be
indicated by the ICMPv6 error message, they should be an input to the
REAP mechanism as a hint.  That seems reasonable.

> > Better to replace "5 minutes" with certain protocol constant
> > (i.e. MINIMUM_CONTEXT_TIMEOUT).
> 
> I don't know if this needs to be a constant; different implementations 
> can pick different values based on their judgement of how long their 
> applications might use a context when there is no connected socket. For 
> instance, an implementation that uses different APIs than the socket API 
> might be able to know all the references applications retain to remote 
> IP addresses, in which case it can tear things down immediately when the 
> last reference is gone.
> So I think 5 minutes is an example.

Ok, I agree that duration of tear down timeout depends on use cases.
As the text says "A reasonable approach would be to ...", so the "5 minutes"
should be regarded as an example.

> >> 11.1  Sending ULP Payload after a Switch
> 
> > What about the next header field in the IPv6 protocol header ? I believe
> > that SHIM6 should override the next header field of IPv6 protocol header
> > when locator switch is performed.  The new protocol value for SHIM6
> > (IPPROTO_SHIM6 ?) is to be assigned by IANA.  Is my understanding
> > correct ?
> 
> You're correct. I've added that description.

Ok.

Regards,
Shinta

Delivery-date: Wed, 15 Feb 2006 00:37:45 +0000
Date: Tue, 14 Feb 2006 16:36:02 -0800
From: Erik Nordmark <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-03

Shinta Sugimoto wrote:
> Hello,
> 
> Let me post my comments on draft-ietf-shim6-proto-03.  I have not read
> the whole document yet, but here are my comments/questions from Section
> 1 to Section 14.  Some are editorial, some are technical.  I will
> continue to read rest of the document and send more comments later.

Thanks for your comments and sorry for the tardy response.
I've used your comments as an indication where we can make the document 
more clear, and I've applied your typo fixes.

>>    o  No extra roundtrip for setup; deferred setup.
> 
> I am not sure what does the above (fourth) bullet mean.  Does
> "deferred setup" mean context establishment follows the IP transaction
> based on the ULID pair ?

What it means (and I'll clarify the document) is that we don't require 
some extra shim6 handshake before TCP/UDP/etc packets can flow. Instead 
normal TCP/UDP/whatever packets can flow and later and in parallel the 
shim6 context can be setup.

> I am not sure if there is semantic difference between "load balancing"
> and "load spreading", but the former sounds more familiar to me.

I'll switch back to "balancing" since that is more common.

One can make a distinction between "balance" as a way to enforce a 
particular split (e.g., a 50/50 balance), and the techniques in shim6 to 
have different connections (from the same or different hosts) pick at 
random between multiple destination addresses doesn't ensure "balance" - 
a single connection might represent the bulk of the traffic. Hence I 
used "spreading" for this for loose concept.

> Section 1.4 talks about relation to IP Multicast as above.  While I
> agree that applying SHIM6 to the sender of IP Multicast does not seem
> reasonable (in a sense that it requires sender to establish context
> with all the receivers, which is unrealistic) it might be worth taking
> a look at applicability of SHIM6 to the receiver node.  As typical
> scenario of IP multicast would be that the sender node is stationary
> and receiver spreads in the network. It is more likely that receiver
> changes its locator frequently than sender.

The approach doesn't prevent the receiver of multicast to change its 
locators, since the receiver is not explicitly identified; the 
destination address is a multicast address and not the unicast locator 
of the receiver.

> In general, I agree with what is stated in Section 1.5 about renumbering
> implications.  Particularly, we should consider how a host treats the
> ULID which becomes unavailable.  In such case, at least the ULID should
> be removed from the physical interface and marked as
> "still-in-use-but-to-be-soon-removed."  The active connection which is
> based on the ULID may continue but the ULID should not be used for new
> connections.

I see the text is missing the introductory material which explains that 
the "locator role" of the IPv6 address can be renumbered away; it is the 
"ULID role" which raises the issue. I'll start the section as:
<t>As stated above, this approach does not try to make communication
survive renumbering in the general case.</t>

<t>When a host is renumbered, the effect is that one or more locators become
invalid, and zero or more locators are added to the host's network 
interface.
This means that the set of locators that is used in the shim will change,
which the shim can handle as long as not all the original locators become
invalid at the same time.</t>

<t>But IP addresses are also used as ULID, and making the communication
survive locators becoming invalid can potentially cause some confusion 
at the
upper layers. <old text>

> IMHO, it would be good to mention that IP addresses to be specified in
> selector information of security policy should be ULID (if locator agility
> is required).  I expect that even IKEv1/IKEv2 would also be possible to
> run over SHIM6, for instance.

I'll add something.

>> 1.7  Traffic Engineering
>>
>>    At the time of this writing it is not clear what requirements for
>>    traffic engineering make sense for the shim6 protocol, since the
>>    requirements must both result in some useful behavior as well as be
>>    implementable using a host-to-host locator agility mechanism like
>>    shim6.  What is clear that whatever they are, shim6 will not be able
>>    to provide identical capabilities to traffic engineering using BGP
>>    and Provide Independent IP addresses.
> 
> It was not clear to me what the above paragraph means.
> Could someone elaborate more on this ?

Let me know if this is more clear:

Inherent in a scalable multihoming mechanism that separates locators 
from identifiers is that each host ends up with multiple locators.
This means that at least for initial contact, it is the remote peer that 
needs to select which peer locator to try first. In the case of shim6 
this is performed by applying RFC 3484 address selection.

This is quite different than the common case of IPv4 multihoming where 
the site has a single IP address prefix, since in that case the peer 
performs no destination address selection.

Thus in "single prefix multihoming" the site, and in many cases its 
upstream ISPs, can use BGP to exert some control of the ingress used to 
reach the site. This capability can't easily be recreated in "multiple 
prefix multihoming" such as shim6.

> ...[snip]...
>>    Current locator pair Each end of the context has a current locator
>>                        pair which is used to send packets to be peer.
>>                        The two ends might use different current locator
>>                        pairs though.
> 
> Is this true ?  My understanding is that the two ends (I and R) must
> have exactly the same current locator pair for the bi-directional
> context.  Otherwise, I guess receiver node maybe confused when it
> tries to demux the receiving packet.  Could someone help me clarify ?

They can be different. The locator *sets* known by the two ends will be 
the same, but each end can independently decide to switch over to use a 
different locator pair for the packets it is sending.

The receiver uses the set of locator pairs for the demux in combination 
with the context tag. For the data packets the 47-bit context tag is all 
the receiver needs to check for demuxing.

>>    Forked Instance Identifier (FII) In order to handle context forking,
>>                        a context is identified by a ULID-pair and a
>>                        forked context identifier.  The default context
>>                        has a FII of zero.
> 
> Is any specific data type defined for FII (eg. unsigned int) ?

Presumably a future ULP-to-SHIM6 API document will define the exact data 
type. Presumably one doesn't have to support a lot of forked contexts, 
thus a 32-bit FII would certainly be sufficient.

>>    o  Some heuristic on A or B (or both) determine that it might make
>>       sense to make this communication robust against locator failures.
>>       For instance, this heuristic might be that more than 50 packets
> 
> s/heuristic/heuristics/

Singular form is without the 's' AFAIK.

>>    o  In addition to failures detected based on end-to-end observations,
>>       one endpoint might be know for certain that one or more of its
> 
> s/know/known/

s/be// is even better

> I think this is an interesting issue.  Assuming that node A sends packet
> to B traversing the tunneling agent C; if the packet from node A happens
> to be tunneled by C to B, we have several choices how to apply SHIM6.
> I think the consequence would be depending on which entities establish
> context.  Let me expand it a little bit more.
> 
> a) If A and B establish SHIM6 context, a packet received by node B would
> look like:
> 
> 	[Outer IP header]
> 		src=C, dst=B
> 	[Inner IP header]
> 		src=L(A), dst=L(B) 
> 	[Shim6 Extension header]
> 	...(Payload)...
> 
> b) If C and B establish SHIM6 context, a packet received by node B would
> look like:
> 
> 	[Outer IP header]
> 		src=L(C), dst=L(B)
> 	[Shim6 Extension header]
> 	[Inner IP header]
> 		src=A, dst=B 
> 	...(Payload)...

Yes, those options do exist.
b) is basically applying a shim to the tunnel itself, and perhaps there 
will be some use for this in some cases.

>>    In most cases IP-in-IP tunnels are used as a routing technique, thus
>>    it makes sense to apply them on the locators which means that the
>>    sender would insert the shim6 header after any IP-in-IP
>>    encapsulation; this is what occurs naturally when routers apply IP-
>>    in-IP encapsulation.
> 
> I would like to have clarification which case a) or b) does the above
> sentence means.  IMHO, both a) and b) should be possible.  b) is slightly
> complex in a sense that SHIM6 packet processing takes place after
> forwarding is done (at the router, namely node C in this case) at the
> IP layer however it remains logical.  Any comments ?

For Mobile IPv6 tunnels (which was on my mind when writing the above) it 
makes sense to apply the shim above the tunneling layer.
So the text does refer to case a), even if that's hard to see from 
reading it.

I'll use your text to more clearly state the options.

>> 7.4  Context confusion
>>
> 
> ...[snip]...
> 
>>    The requirement is that the old context which used the context tag
>>    MUST be removed; it can no longer be used to send packets.
> 
> Yes, but we should note one thing: Even if a node receives I1 message
> with a duplicated context tag proposed by the other end, receiver node
> should not delete old context until the context establishment is
> successfully done.

Yes, I think that text exists in the detailed descriptions in 7.7 etc, 
but it makes sense to add it in 7.4 as well.

>>
>>    o  If the state is ESTABLISHED, it means that the Initiator has lost
>>       the context information for this context and it is trying to
>>       establish a new one.  In this case, the host MUST update the
>>       existing context and replace CT(peer) with the Initiator Context
>>       Tag included in the I1 message and then reply with an R2 message,
>>       including the associated state information.  In this case the host
>>       MUST look for any other (old) context with a matching CT(peer) as
>>       specified in Section 7.12.  This completes the I1 processing, with
>>       the context state being unchanged.
> 
> Same as my previous comment, but I believe the above rule is not good
> because it may allow malicious node to send false I1 message (by possibly
> spoofing the source IP address) and delete corresponding context.

Correct. I think Marcelo had found this, but not send it to the mailing 
list. Basically we shouldn't update CT(peer) until after a 3-way handshake.

>>    If at least one of the above verification fails, then it silently
>>    discard the packet and it has completed the I2 processing.
> 
> IMHO, it is better to rephrase above paragraph as below:
> "If any of the above verification fails, the host MUST silently discard
> the packet and complete the I2 processing."

Yes, that's better.

>> 7.12  Match for Context Confusion
>>
>>    When the host receives an I2, I2bis, or R2 it MUST look for a
> 
> similar (might be same) comment again, but I believe the verification
> discussed here should be applied for I2bis and R2 message.  For I2
> message, if the CT looks different from the one appeared on I1 message,
> the I2 message should be considered invalid.

I don't understand the case. There is no state created on the reception 
of the I1. But the initiator can't change the CT because it is included 
in the verifier option computation. So what case do you think is 
problematic?

> I understand it is necessary to restore the original packet included in
> the ICMP error message.  Besides, I wonder if there is any kind of ICMP
> error message to which SHIM6 protocol stack should react (e.g. changing
> state of corresponding context).  For instance, if the node receives
> host unreach, should the corresponding host pair context be torn down ?

The draft-ietf-shim6-failure-detection-03.txt document treats those as 
hints. In any case, they are not used to fail the shim6 context/ULID but 
a hint that the destination locator is unreachable.

> Better to replace "5 minutes" with certain protocol constant
> (i.e. MINIMUM_CONTEXT_TIMEOUT).

I don't know if this needs to be a constant; different implementations 
can pick different values based on their judgement of how long their 
applications might use a context when there is no connected socket. For 
instance, an implementation that uses different APIs than the socket API 
might be able to know all the references applications retain to remote 
IP addresses, in which case it can tear things down immediately when the 
last reference is gone.
So I think 5 minutes is an example.

>> 11.1  Sending ULP Payload after a Switch

> What about the next header field in the IPv6 protocol header ? I believe
> that SHIM6 should override the next header field of IPv6 protocol header
> when locator switch is performed.  The new protocol value for SHIM6
> (IPPROTO_SHIM6 ?) is to be assigned by IANA.  Is my understanding
> correct ?

You're correct. I've added that description.

    Erik

Delivery-date: Thu, 02 Feb 2006 23:46:23 +0000
Date: Fri, 03 Feb 2006 10:42:47 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SIDR Charter

Hi,

please ignore my last posting - my mailbook and I are suffering from mutual 
confusion and I misdirected this note!!

:-)

   Geoff

-----------
Hi,

Alex and Bill have reported back on the IESG's consideration of the
proposed SIDR Charter.

They've asked us to see if we can submit a revised charter early next
week that addresses the following comments:

1. Para that says:

 >  Both strict hierarchical and distributed non-
 >  hierarchical trust systems are intended to be supported within
 >  this framework.

    should also say that the reason for this is that they are both needed,
    each for a different deployment model.

2. The charter speaks about authentication, but not about authorization,
    and it should.

For reference the proposed charter is attached to this note

The next note will detail suggested changes to the proposed charter to
address these comments, for your consideration.

Regards,

     Geoff

===========================================================================

Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28 (V4)

Chair(s):
   TBD

Routing Area Director(s):
   Bill Fenner <fenner at research.att.com>
   Alex Zinin <zinin at psg.com>

Routing Area Advisor:
   TBD

Other Advisors:
   ? Security: TBD
   ? Routing: TBD

Mailing Lists:
   General Discussion: sidr at ietf.org
   To Subscribe: sidr-request at ietf.org
   In Body: (un)subscribe
   Archive: http://www.ietf.org/mail-archive/web/sidr/index.html

Description of Working Group:

   One of the areas of vulnerability for large scale Internet
   environments lies in the area of inter-domain routing. The basic
   security questions that can be posed regarding routing information
   is that of the validity of the address prefix being advertised, the
   validity of the originating Autonomous System Number, and the
   existence of an explicit permission from the address prefix holder
   to allow the prefix to be advertised from this origin. A related
   question concerns the level of trust than can be ascribed to
   attributes of a route object in terms of their authenticity,
   including consideration of the AS Path attribute..

   The Routing Protocol Security Group (RPSEC) has been chartered to
   document the security requirements for routing systems, and, in
   particular, to produce a document on BGP security requirements.

   The scope of work in the SIDR working group is to formulate an
   extensible architecture for an interdomain routing security
   framework. This framework must be capable of supporting incremental
   additions of functional components. As and when interdomain routing
   security requirements are completed within the RPSEC Working Group,
   these requirements will be defined within the SIDR framework as
   functional components of a secure interdomain routing system.

   The scope of work will include describing the use of certification
   objects for supporting the distribution of authentication
   information. Both strict hierarchical and distributed non-
   hierarchical trust systems are intended to be supported within
   this framework.

   The scope of work is limited to inter-domain router-to-router
   protocols only, for both unicast and multicast systems.

   The SIDR working group is charged with the following tasks:

   - Document an extensible interdomain routing security architecture

   - Document the use of certification objects within this secure
     routing architecture

   - Document specific routing functionality modules within this
     architecture that are designed to address specific secure routing
     requirements as they are determined by the RPSEC Working Group

Goals and Milestones:

April-06  Submit initial draft on inter-domain routing security
           architecture

May-06    Submit  initial draft on certificate objects to be used
           within this architecture

May-06    Submit initial draft on securing origination of routing
           information

Sept-06   Submit routing security architecture for publication as an
           Informational RFC

Nov-06    Submit description of use certificate objects by this
           architecture as an Informational RFC

Dec-06    Submit secure origination mechanism as a Proposed Standard

Jan-07    Evaluate progress, recharter with new goals or shutdown.

Delivery-date: Thu, 02 Feb 2006 23:18:01 +0000
Date: Fri, 03 Feb 2006 10:16:53 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SIDR Charter

Hi,

Alex and Bill have reported back on the IESG's consideration of the
proposed SIDR Charter.

They've asked us to see if we can submit a revised charter early next
week that addresses the following comments:

1. Para that says:

 >  Both strict hierarchical and distributed non-
 >  hierarchical trust systems are intended to be supported within
 >  this framework.

    should also say that the reason for this is that they are both needed,
    each for a different deployment model.

2. The charter speaks about authentication, but not about authorization,
    and it should.

For reference the proposed charter is attached to this note

The next note will detail suggested changes to the proposed charter to
address these comments, for your consideration.

Regards,

     Geoff

===========================================================================

Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28 (V4)

Chair(s):
   TBD

Routing Area Director(s):
   Bill Fenner <fenner at research.att.com>
   Alex Zinin <zinin at psg.com>

Routing Area Advisor:
   TBD

Other Advisors:
   ? Security: TBD
   ? Routing: TBD

Mailing Lists:
   General Discussion: sidr at ietf.org
   To Subscribe: sidr-request at ietf.org
   In Body: (un)subscribe
   Archive: http://www.ietf.org/mail-archive/web/sidr/index.html

Description of Working Group:

   One of the areas of vulnerability for large scale Internet
   environments lies in the area of inter-domain routing. The basic
   security questions that can be posed regarding routing information
   is that of the validity of the address prefix being advertised, the
   validity of the originating Autonomous System Number, and the
   existence of an explicit permission from the address prefix holder
   to allow the prefix to be advertised from this origin. A related
   question concerns the level of trust than can be ascribed to
   attributes of a route object in terms of their authenticity,
   including consideration of the AS Path attribute..

   The Routing Protocol Security Group (RPSEC) has been chartered to
   document the security requirements for routing systems, and, in
   particular, to produce a document on BGP security requirements.

   The scope of work in the SIDR working group is to formulate an
   extensible architecture for an interdomain routing security
   framework. This framework must be capable of supporting incremental
   additions of functional components. As and when interdomain routing
   security requirements are completed within the RPSEC Working Group,
   these requirements will be defined within the SIDR framework as
   functional components of a secure interdomain routing system.

   The scope of work will include describing the use of certification
   objects for supporting the distribution of authentication
   information. Both strict hierarchical and distributed non-
   hierarchical trust systems are intended to be supported within
   this framework.

   The scope of work is limited to inter-domain router-to-router
   protocols only, for both unicast and multicast systems.

   The SIDR working group is charged with the following tasks:

   - Document an extensible interdomain routing security architecture

   - Document the use of certification objects within this secure
     routing architecture

   - Document specific routing functionality modules within this
     architecture that are designed to address specific secure routing
     requirements as they are determined by the RPSEC Working Group

Goals and Milestones:

April-06  Submit initial draft on inter-domain routing security
           architecture

May-06    Submit  initial draft on certificate objects to be used
           within this architecture

May-06    Submit initial draft on securing origination of routing
           information

Sept-06   Submit routing security architecture for publication as an
           Informational RFC

Nov-06    Submit description of use certificate objects by this
           architecture as an Informational RFC

Dec-06    Submit secure origination mechanism as a Proposed Standard

Jan-07    Evaluate progress, recharter with new goals or shutdown.

Delivery-date: Thu, 02 Feb 2006 09:39:53 +0000
Date: Thu, 02 Feb 2006 18:38:20 +0900
From: Shinta Sugimoto <[email-masked]>
To: [email-masked]
Subject: comments on draft-ietf-shim6-proto-03

Hello,

Let me post my comments on draft-ietf-shim6-proto-03.  I have not read
the whole document yet, but here are my comments/questions from Section
1 to Section 14.  Some are editorial, some are technical.  I will
continue to read rest of the document and send more comments later.

=46rom 1.1 Goals:

>    The goals for this approach is to:
>=20
>    o  Preserve established communications through failures, for example,
>       TCP connections and application communications using UDP.
>=20
>    o  Have no impact on upper layer protocols in general and on
>       transport protocols in particular.
>=20
>    o  Address the security threats in [20] through a separate document
>       [7], and techniques described in this document.
>=20
>    o  No extra roundtrip for setup; deferred setup.

I am not sure what does the above (fourth) bullet mean.  Does
"deferred setup" mean context establishment follows the IP transaction
based on the ULID pair ?

>=20
>    o  Take advantage of multiple locators/addresses for load spreading
>       so that different sets of communication to a host (e.g., different
>       connections) might use different locators of the host.  This might
>       enable some forms of traffic engineering, but the details for
>       traffic engineering, including what requirements can be satisfied,
>       have not yet been worked out.
>=20

I am not sure if there is semantic difference between "load balancing"
and "load spreading", but the former sounds more familiar to me.

> 1.4  IP Multicast
>=20
>    IP Multicast requires that the IP source address field contain a
>    topologically correct locator for interface that is used to send the
>    packet, since IP multicast routing uses both the source address and
>    the destination group to determine where to forward the packet.
>    (This isn't much different than the situation with widely implemented
>    ingress filtering [11] for unicast.)
>=20
>    While in theory it would be possible to apply the shim re-mapping of
>    the IP address fields between ULIDs and locators, the fact that all
>    the multicast receivers would need to know the mapping to perform,
>    makes such an approach difficult in practice.  Thus it makes sense to
>    have multicast ULPs operate directly on locators and not use the
>    shim.  This is quite a natural fit for protocols which use RTP [15],
>    since RTP already has an explicit identifier in the form of the SSRC
>    field in the RTP headers.  Thus the actual IP address fields are not
>    important to the application.
>=20
>    In summary, IP multicast will not use the shim to remap the IP
>    addresses.

Section 1.4 talks about relation to IP Multicast as above.  While I
agree that applying SHIM6 to the sender of IP Multicast does not seem
reasonable (in a sense that it requires sender to establish context
with all the receivers, which is unrealistic) it might be worth taking
a look at applicability of SHIM6 to the receiver node.  As typical
scenario of IP multicast would be that the sender node is stationary
and receiver spreads in the network. It is more likely that receiver
changes its locator frequently than sender.

> 1.5  Renumbering Implications
=2E..
[snip]
=2E..
>    However, terminating the communication might be overkill.  Even when
>    an IPv6 prefix is retired and reassigned to some other site, there is
>    a very small probability that another host in that site picks the
>    same 128 bit address (whether using DHCPv6, stateless address
>    autoconfiguration, or picking a random interface ID [12]).  Should
>    the identical address be used by another host, then there still
>    wouldn't be a problem until that host attempts to communicate with
>    the same peer host with which the initial user of the IPv6 address
>    was communicating.
>=20
>    The protocol as specified in this document does not perform any
>    action when an address becomes invalid.  As we gain further
>    understanding of the practical impact of renumbering this might
>    change in a future version of the protocol.

In general, I agree with what is stated in Section 1.5 about renumbering
implications.  Particularly, we should consider how a host treats the
ULID which becomes unavailable.  In such case, at least the ULID should
be removed from the physical interface and marked as
"still-in-use-but-to-be-soon-removed."  The active connection which is
based on the ULID may continue but the ULID should not be used for new
connections.

> 1.6  Placement of the shim
=2E.. [snip] ...

>    Layering AH and ESP above the multihoming shim means that IPsec can
>    be made to be unaware of locator changes the same way that transport
>    protocols can be unaware.  Thus the IPsec security associations
>    remain stable even though the locators are changing.

IMHO, it would be good to mention that IP addresses to be specified in
selector information of security policy should be ULID (if locator agility
is required).  I expect that even IKEv1/IKEv2 would also be possible to
run over SHIM6, for instance.

> 1.7  Traffic Engineering
>=20
>    At the time of this writing it is not clear what requirements for
>    traffic engineering make sense for the shim6 protocol, since the
>    requirements must both result in some useful behavior as well as be
>    implementable using a host-to-host locator agility mechanism like
>    shim6.  What is clear that whatever they are, shim6 will not be able
>    to provide identical capabilities to traffic engineering using BGP
>    and Provide Independent IP addresses.

It was not clear to me what the above paragraph means.
Could someone elaborate more on this ?

> 2.1  Definitions
>=20

I think it's better to add definition for "locator agility" which is
one of the key concepts of SHIM6.  It might also be helpful to describe
what the "demultiplex" means.

=2E..[snip]...
>    Current locator pair Each end of the context has a current locator
>                        pair which is used to send packets to be peer.
>                        The two ends might use different current locator
>                        pairs though.

Is this true ?  My understanding is that the two ends (I and R) must
have exactly the same current locator pair for the bi-directional
context.  Otherwise, I guess receiver node maybe confused when it
tries to demux the receiving packet.  Could someone help me clarify ?

>    Forked Instance Identifier (FII) In order to handle context forking,
>                        a context is identified by a ULID-pair and a
>                        forked context identifier.  The default context
>                        has a FII of zero.

Is any specific data type defined for FII (eg. unsigned int) ?

> 4.  Protocol Overview
>=20
=2E..[snip]...
>    o  Some heuristic on A or B (or both) determine that it might make
>       sense to make this communication robust against locator failures.
>       For instance, this heuristic might be that more than 50 packets

s/heuristic/heuristics/

>       have been sent or received, or a timer expiration while active
>       packet exchange is in place.  This makes the shim initiate the
>       4-way context establishment exchange.
>=20

=2E..[snip]...

>    o  In addition to failures detected based on end-to-end observations,
>       one endpoint might be know for certain that one or more of its

s/know/known/

=2E..[snip]...

> 4.6  Extension Header Order
>=20
>    Since the shim is placed between the IP endpoint sub-layer and the IP
>    routing sub-layer in the host, the shim header MUST be placed before
>    any endpoint extension headers (fragmentation headers, destination
>    options header, AH, ESP), but after any routing related headers (hop-
>    by-hop extensions header, routing header, a destinations options
>    header which precedes a routing header).  When tunneling is used,
>    whether IP-in-IP tunneling or the special form of tunneling that
>    Mobile IPv6 uses (with Home Address Options and Routing header type
>    2), there is a choice whether the shim applies inside the tunnel or
>    outside the tunnel, which effects the location of the shim6 header.

I think this is an interesting issue.  Assuming that node A sends packet
to B traversing the tunneling agent C; if the packet from node A happens
to be tunneled by C to B, we have several choices how to apply SHIM6.
I think the consequence would be depending on which entities establish
context.  Let me expand it a little bit more.

a) If A and B establish SHIM6 context, a packet received by node B would
look like:

	[Outer IP header]
		src=3DC, dst=3DB
	[Inner IP header]
		src=3DL(A), dst=3DL(B)=20
	[Shim6 Extension header]
	...(Payload)...

b) If C and B establish SHIM6 context, a packet received by node B would
look like:

	[Outer IP header]
		src=3DL(C), dst=3DL(B)
	[Shim6 Extension header]
	[Inner IP header]
		src=3DA, dst=3DB=20
	...(Payload)...

>    In most cases IP-in-IP tunnels are used as a routing technique, thus
>    it makes sense to apply them on the locators which means that the
>    sender would insert the shim6 header after any IP-in-IP
>    encapsulation; this is what occurs naturally when routers apply IP-
>    in-IP encapsulation.

I would like to have clarification which case a) or b) does the above
sentence means.  IMHO, both a) and b) should be possible.  b) is slightly
complex in a sense that SHIM6 packet processing takes place after
forwarding is done (at the router, namely node C in this case) at the
IP layer however it remains logical.  Any comments ?

> 7.4  Context confusion
>=20

=2E..[snip]...

>    The requirement is that the old context which used the context tag
>    MUST be removed; it can no longer be used to send packets.

Yes, but we should note one thing: Even if a node receives I1 message
with a duplicated context tag proposed by the other end, receiver node
should not delete old context until the context establishment is
successfully done.

=2E..[snip]...

> 7.7  Receiving I1 messages
>=20
>    A host MUST silently discard any received I1 messages that do not
>    satisfy all of the following validity checks in addition to those
>    specified in Section 12.2:
>=20
>    o  The Hdr Ext Len field is at least 1, i.e., the length is at least
>       16 octets.
>=20
>    Upon the reception of an I1 message, the host extracts the ULID pair
>    and the Forked Instance identifier from the message.  If there is no
>    ULID-pair option, then the ULID pair is taken from the source and
>    destination fields in the IPv6 header.  If there is no FII option in
>    the message, then the FII value is taken to be zero.
>=20
>    Next the host looks for an existing context which matches the ULID
>    pair and the FII.  If such a context exists, the host verifies that
>    the locator of the Initiator is included in Ls(peer) (This check is
>    unnecessary if there is no ULID-pair option in the I1 message).  If
>    the locators do not fall in the locator sets, then the host MUST
>    discard the I1 packet and perform no further processing.
>=20
>    If no state is found (i.e., the state is IDLE), or the locators do
>    fall in the sets, then the host looks at the state of the context:
>=20
>    o  If the state is IDLE, then the host will form an R1 packet as
>       specified below.
>=20
>    o  If the state is ESTABLISHED, it means that the Initiator has lost
>       the context information for this context and it is trying to
>       establish a new one.  In this case, the host MUST update the
>       existing context and replace CT(peer) with the Initiator Context
>       Tag included in the I1 message and then reply with an R2 message,
>       including the associated state information.  In this case the host
>       MUST look for any other (old) context with a matching CT(peer) as
>       specified in Section 7.12.  This completes the I1 processing, with
>       the context state being unchanged.

Same as my previous comment, but I believe the above rule is not good
because it may allow malicious node to send false I1 message (by possibly
spoofing the source IP address) and delete corresponding context.

> 7.8  Receiving R1 messages and sending I2 messages
>=20
>    A host MUST silently discard any received R1 messages that do not
>    satisfy all of the following validity checks in addition to those
>    specified in Section 12.2:
>=20
>    o  The Hdr Ext Len field is at least 1, i.e., the length is at least
>       16 octets.
>=20
>    Upon the reception of an R1 message, the host extracts the Initiator
>    Nonce and the Locator Pair from the message (the latter from the
>    source and destination fields in the IPv6 header).  Next the host
>    looks for an existing context which matches the Initiator Nonce and
>    where the locators are contained in Ls(peer) and Ls(local),
>    respectively.  If no such context is not found, then the R1 packet is
>    silently discarded.

s/no such context is not/no such context is/

> 7.10  Receiving I2 messages
>=20
>    A host MUST silently discard any received I2 messages that do not
>    satisfy all of the following validity checks in addition to those
>    specified in Section 12.2:
>=20
>    o  The Hdr Ext Len field is at least 2, i.e., the length is at least
>       24 octets.
>=20
>    Upon the reception of an I2 message, the host extracts the ULID pair
>    and the Forked Instance identifier from the message.  If there is no
>    ULID-pair option, then the ULID pair is taken from the source and
>    destination fields in the IPv6 header.  If there is no FII option in
>    the message, then the FII value is taken to be zero.
>=20
>    Next the host verifies that the Responder Nonce is a recent one, and
>    that the Validator option matches the validator the host would have
>    computed for the ULID, locators, responder nonce, and FII.
>=20
>    If a CGA Parameter Data Structure is included in the message, then
>    the host MUST verify if the actual PDS contained in the packet
>    corresponds to the ULID(peer).
>=20
>    If at least one of the above verification fails, then it silently
>    discard the packet and it has completed the I2 processing.

IMHO, it is better to rephrase above paragraph as below:
"If any of the above verification fails, the host MUST silently discard
the packet and complete the I2 processing."

=2E..[snip]...

> 7.12  Match for Context Confusion
>=20
>    When the host receives an I2, I2bis, or R2 it MUST look for a

similar (might be same) comment again, but I believe the verification
discussed here should be applied for I2bis and R2 message.  For I2
message, if the CT looks different from the one appeared on I1 message,
the I2 message should be considered invalid.

>    possible context confusion i.e. where it would end up with multiple
>    contexts using the same CT(peer) for the same peer host.  This can
>    happen when it has received the above messages since they create a
>    new context with a new CT(peer).  Same issue applies when CT(peer) is
>    updated for an existing context.
>=20
>    The host takes CT(peer) for the newly created or updated context, and
>    looks for other contexts which:
>=20
>    o  Are in state ESTABLISHED or I2BIS-SENT.
>=20
>    o  Have the same CT(peer).
>=20
>    o  Where Ls(peer) has at least one locator in common with the newly
>       created or updated context.
>=20
>    If such a context is found, then the host checks if the ULID pair or
>    the Forked Instance Identifier different than the ones in the newly
>    created or updated context:
>=20
>    o  If this is true, then the peer is trying to reuse the context tag
>       for the creation of a context with different ULID pair or FII,
>       which is a signal that the Initiator has lost the other context.
>       In this case, we are in the Context confusion situation, and the
>       host MUST NOT use the old context to send any packets.  It MAY
>       just discard the old context (after all, the peer has discarded
>       it), or it MAY attempt to re-establish the old context by sending
>       a new I1 message and moving its state to I1-SENT.  In any case,
>       once that this situation is detected, the host MUST not keep two

s/MUST not/MUST NOT/

>       contexts with overlapping Ls(peer) locator sets and the same
>       context tag in ESTABLISHED state, since this would result in
>       demultiplexing problems on the peer.
>=20
>    o  If this is not true, then the local host must be broken, since it
>       should have detected the existence of a context for the same ULID
>       pair and FII earlier.
>=20

=2E..[snip]...

> 7.15  Receiving R1bis messages and sending I2bis messages
>=20
>    A host MUST silently discard any received R1bis messages that do not
>    satisfy all of the following validity checks in addition to those
>    specified in Section 12.2:
>=20
>    o  The Hdr Ext Len field is at least 1, i.e., the length is at least
>       16 octets.
>=20
>    Upon the reception of an R1bis message, the host extracts the Packet
>    Context Tag and the Locator Pair from the message (the latter from
>    the source and destination fields in the IPv6 header).  Next the host
>    looks for an existing context where the Packet Context Tag matches
>    CT(peer) and where the locators match Lp(peer) and Lp(local),
>    respectively.
>=20
>    o  If no such context is not found, i.e., the state is IDLE, then the
>       R1bis packet is silently discarded.
>=20
>    o  If the state is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis
>       packet is silently discarded.
>=20
>    o  If the state is ESTABLISHED, then we are in the case where the
>       peer has lost the context and the goal is to try to re-establish
>       it.  For that, the host leaves CT(peer) unchanged in the context
>       state, transitions to I2BIS-SENT state, and sends a I2bis packet,
>       including in it the Validator, the Packet Context Tag, and the

s/including in it/including it in/

> 8.  Handling ICMP Error Messages

=2E..[snip]...

>    If the ULP packet had been encapsulated in a shim6 payload extension
>    header, then this extension header must be removed.  The result needs
>    to be that the ULP receives an ICMP error where the contained "packet
>    in error" looks as if the shim did not exist.

I understand it is necessary to restore the original packet included in
the ICMP error message.  Besides, I wonder if there is any kind of ICMP
error message to which SHIM6 protocol stack should react (e.g. changing
state of corresponding context).  For instance, if the node receives
host unreach, should the corresponding host pair context be torn down ?

> 9.  Teardown of the ULID-Pair Context
>=20
>    Each host can unilaterally decide when to tear down a ULID-pair
>    context.  It is RECOMMENDED that hosts not tear down the context when

s/hosts not/hosts do not/

>    they know that there is some upper layer protocol that might use the
>    context.  For example, an implementation might know this is there is

s/this is there is/this if there is/ ?

>    an open socket which is connected to the ULID(peer).  However, there
>    might be cases when the knowledge is not readily available to the
>    shim layer, for instance for UDP applications which not connect their

s/which not connect/which do not connect/

>    sockets, or any application which retains some higher level state
>    across (TCP) connections and UDP packets.
>=20
>    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 to not tear down a context

s/to not/not to/

>    until at least 5 minutes have passed since the last message was sent
>    or received using the context.

Better to replace "5 minutes" with certain protocol constant
(i.e. MINIMUM_CONTEXT_TIMEOUT).

>    Since there is no explicit, coordinated removal of the context state,
>    there are potential issues around context tag reuse.  One end might
>    remove the state, and potentially reuse that context tag for some
>    other communication, and the peer might later try to use the old
>    context (which it didn't remove).  The protocol has mechanisms to
>    recover from this, which work whether the state removal was total and
>    accidental (e.g., crash and reboot of the host), or just a garbage
>    collection of shim state that didn't seem to be used.  However, the
>    host should try to minimize the reuse of context tags by trying to
>    randomly cycle through the 2^47 context tag values.  (See Appendix B
>    for a summary how the recovery works in the different cases.)

=2E..[snip]...

> 11.1  Sending ULP Payload after a Switch
>=20
>    When sending packets, if there is a ULID-pair context for the ULID
>    pair, and the ULID pair is no longer used as the locator pair, then
>    the sender needs to transform the packet.  Apart from replacing the
>    IPv6 source and destination fields with a locator pair, an 8-octet
>    header is added so that the receiver can find the context and inverse
>    the transformation.
>=20
>    First, the IP address fields are replaced.  The IPv6 source address
>    field is set to Lp(local) and the destination address field is set to
>    Lp(peer).  NOTE that this MUST NOT cause any recalculation of the ULP
>    checksums, since the ULP checksums are carried end-to-end and the ULP
>    pseudo-header contains the ULIDs which are preserved end-to-end.
>=20
>    The sender skips any "routing sub-layer extension headers" that the
>    ULP might have included, thus it skips any hop-by-hop extension
>    header, any routing header, and any destination options header that
>    is followed by a routing header.  After any such headers the shim6
>    extension header will be added.  This might be before a Fragment
>    header, a Destination Options header, an ESP or AH header, or a ULP
>    header.
>=20
>    The inserted shim6 Payload extension header includes the peer's
>    context tag.

What about the next header field in the IPv6 protocol header ? I believe
that SHIM6 should override the next header field of IPv6 protocol header
when locator switch is performed.  The new protocol value for SHIM6
(IPPROTO_SHIM6 ?) is to be assigned by IANA.  Is my understanding
correct ?

Regards,
Shinta