Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

[marcelo bagnulo braun <[e-mail]>]

Hi Scott,

> I disagree with this.  If a rewriting-capable host, which may or may 
> not
> have a rewriting router on the path, started up communication observing
> these SHOULDs, then the host it's talking to, which may be a very busy
> non-multihomed (or PI-multihomed) server, would have to keep full shim6
> context and would be unable to discard it during communication due to 
> the
> presence of shim6 extension headers on every packet.  This would be 
> true
> even if no source-rewriting routers were deployed, and no one gained 
> any
> benefit from the capability.
>
> IMO a better approach would be to continue using deferred context
> establishment (except in the identifier/locator split case, of course),
> and initially only put the Sent Locator Pair option packets that 
> already
> have shim6 headers (shim6 control packets and any packets sent with
> non-ULID locators).  Then, *if* source locator rewriting is done by a
> router on *those* packets, you can start putting shim6 extension 
> headers
> on all ULP payload packets.
>

I guess that what you want is first to discover if there is s router 
rewriting in the path and if this is so, then enable this capability 
for the particular shim6 context.

The problem that i see with this is that i don't think it is trivial to 
detect if a rewriting router is in the path. In particular, i don't 
think that the context establishment exchenge is enough to detect such 
presence, especially because it may well happen that during the context 
estbalihsment exchenge, the source address match with what the router 
would have rewritten, and even if there is a rewriting router in the 
path, the source address is unchanged.

I guess it hard to have both aggresive garbage collection and source 
address rewriting and i guess each site will preffer one capability 
over the other. So i guess that the best we could do is to provide 
tools so that each site can benefit from the capability that it 
preffers the most.

Regards, marcelo


> My reasoning for wanting to make the changes above is that IMO there 
> will
> be a lot more users who want to minimize shim6 state on their servers 
> than
> who want to do shim6 rewriting in their routers, at least initially.  
> If
> we start requiring all packets between shim6-capable hosts to have 
> shim6
> extension headers, that requires that all shim6-capable hosts keep full
> shim6 state for all communications with other shim6-capable hosts, 
> which
> in turn means that operators of large servers will turn off shim6
> entirely, and it will be of very limited utility due to very limited
> deployment.
>
> -Scott
>
> On 03/01/06 at 11:45am -0800, Erik Nordmark <[e-mail]> 
> wrote:
>
>>
>>
>> -------- Original Message --------
>> Subject: I-D ACTION:draft-nordmark-shim6-esd-00.txt
>> Date: Tue, 28 Feb 2006 15:50:02 -0500
>> From: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: Extended Shim6 Design for ID/loc split and
>>                            Traffic Engineering
>> 	Author(s)	: E. Nordmark
>> 	Filename	: draft-nordmark-shim6-esd-00.txt
>> 	Pages		: 25
>> 	Date		: 2006-2-28
>>
>>     The Shim6 protocol provides for locator agility while satisfying 
>> the
>>     'first, do no harm' security requirements.  This document outlines
>>     some extensions to Shim6 that in addition provides complete
>>     separation between identifiers and locators, and allows routers to
>>     rewrite the locators in the shim6 packets as a way to provide 
>> traffic
>>     engineering information to the hosts.
>>
>>     The document also outlines a simple extension to allow shim6, 
>> with a
>>     CGA upper-layer ID, to operate using IPv4 addresses as locators.
>>
>>     The purpose of this outline is to stimulate discussions.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [e-mail] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the 
>> username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> 	"get draft-nordmark-shim6-esd-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[e-mail].
>> In the body type:
>> 	"FILE /internet-drafts/draft-nordmark-shim6-esd-00.txt".
>>
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>