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

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Oct 2004 17:08:17 -0700

-------- Original Message --------
Subject: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt
Date: Tue, 19 Oct 2004 07:48:23 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nordmark-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-masked].
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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Oct 2004 17:15:29 +0200

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ó:

> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Oct 2004 14:32:26 -0700

> need to add an extension header?

The packetization layer (such as TCP) needs to be aware of this,
which isn't any different than how an implementation makes TCP aware
that ESP or AH will be added to a packet, or that it will be subject to
IP-in-IP tunneling overhead.

> guess this is not really compatible with section 7...

I believe you are right, but it might be possible to solve this.

If the attempts to talk to the peer using another AAAA record
(which may or may not point to the same host) include the ULID then the 
peer can respond with "not me", which would allow the multi6
layer to try all the AAAA records which do point at the same host.

Of course, if there is only one AAAA record per host (but multiple AAAA 
records pointing at different hosts) this is just a waste of time.
Even if say, the multi6 layer tries 2 records out of 10 which happen to
point to the same host, but are unreachable (e.g. because the host is 
down), then the application layer needs to try the other 8.
But the application layer wouldn't know that multiple AAAAs have been 
tried by the multi6 shim below; it just has a list of 10 ULIDs to try.
So it would end up trying all 10.

> (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?

It does have different properties, but I don't think it matters in 
practice because it is the mechanism the host uses to learn different 
ULIDs.

    Erik