Re: [Fwd: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt]

marcelo bagnulo braun <[email protected]> Fri, 22 Oct 2004 17:15:29 +0200
Newsgroups gmane.ietf.multi6
Message-ID <355BD00C-243D-11D9-AF09-000D93ACD0FE@it>
Hi Erik,

Some additional issues that i may comment:

When discussing fragmentation in section 5, i guess that the question 
that Margaret raised a while ago is still there i.e. if we place multi6 
below fragmentation, what happens when we have a full MTU packet and we 
need to add an extension header?

In section 8.4 it is stated that:

    This might be the case when the two
    hosts have already communicated, and it might be possible to have the
    DNS resolver library provide alternate locators to the shim in the
    speculation that they might be useful.

I have two issues with this:
- first: wouldn't this impose a new RR or something similar? i mean how 
does the DNS knows that all the locators belong to the same endpoint? i 
guess this is not really compatible with section 7...
- second: this would introduce a new way to learn additional locators 
(the noid like mechanism) This mechanism may have different trust 
levels than the one available for learning locators during the 
communication lifetime. Wouldn't this introduce some trust problems?

Regards, marcelo



El 20/10/2004, a las 2:08, Erik Nordmark escribió:

>
>
> -------- Original Message --------
> Subject: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt
> Date: Tue, 19 Oct 2004 07:48:23 -0400
> From: [email protected]
> Reply-To: [email protected]
> To: [email protected]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Multihoming L3 Shim Approach
> 	Author(s)	: E. Nordmark
> 	Filename	: draft-nordmark-multi6dt-shim-00.txt
> 	Pages		: 20
> 	Date		: 2004-10-18
> 	
> This document outlines an approach to solving IPv6 multihoming in
>    order to stimulate discussion.
>
>    The approach is based on using a multi6 shim placed between the IP
>    endpoint sublayer and the IP routing sublayer, and, at least
>    initially, using routable IP locators as the identifiers visible
>    above the shim layer.  The approach does not introduce a "stack 
> name"
>    type of identifier, instead it ensures that all upper layer 
> protocols
>    can operate unmodified in a multihomed setting while still seeing a
>    stable IPv6 address.
>
>    This document does not specify the mechanism for authenticating and
>    authorizing the "rehoming" - this is specified in the HBA document.
>    Nor does it specify the messages used to establish multihoming 
> state.
>
>    The document does not even specify the packet format used for the
>    data packets.  Instead it discusses the issue of receive side
>    demultiplexing and the different tradeoffs.  The resolution of this
>    issue will effect the packet format for the data packets.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-shim-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email protected] 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-multi6dt-shim-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 protected].
> In the body type:
> 	"FILE /internet-drafts/draft-nordmark-multi6dt-shim-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 protected]>
>
>
> _______________________________________________
> I-D-Announce mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------