[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt]
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?
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
A New Internet-Draft is available from the on-line Internet-Drafts
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
type of identifier, instead it ensures that all upper layer
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
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:
To remove yourself from the I-D Announcement list, send a message to
firstname.lastname@example.org with the word unsubscribe in the body of
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
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
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
I-D-Announce mailing list
Please note that my former email address
email@example.com is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es