Hi Erik,
I think the document is very clear. I have some comments below...
Regards, marcelo
El 11/01/2005, a las 7:08, Erik Nordmark escribió:
1.2. Assumptions
This approach assumes that packets with arbitrary combinations of
source and destination locators will make it from end to end unless
there is some form of failure. Due to the interaction between
ingress filtering [RFC2827] and source address selection, this
assumption might not be true in IPv6 today. As a result there is a
need to work out a solution that doesn't make the ingress filtering
in ISPs drop more packets than needed. Some solutions to this have
been proposed in [INGRESS].
I would say that the assumption being made is even stronger than this.
In addition to what is stated, there is another assumtion being made
w.r.t. to the site exit router selection. Precisely, i think that the
solution assumes that a modification in the source and destination
addresses would result in a change of the site exit path used to route
both incoming and outgoing packets. This assumption holds true
trivially for incoming packets since we are assuming provider
aggregatable addressing, but for the case of outgoing traffic, this is
not trivial and some mechanisms are needed for this (in particular
some of the ingress filtering mechanisms also provide such
functionality, but note that there are some solution for the ingress
filtering compatibility problem (like address rewriting or simply
relaxing ingress filters) that solve the ingress filtering problem but
don't provide this functionality)
2. Terminology
[...]
identifier - an IP layer identifier for an IP layer endpoint
(stack name in [NSRG]). The transport endpoint
is a
^name?
maybe i am not understanding this, but isn't a "name" missing above?
function of the transport protocol and would
typically include the IP identifier plus a port
number. NOTE: This proposal does not contain any
IP
layer identifiers.
upper-layer identifier (ULID)
- an IP locator which has been selected for
Wouldn't be better to substitute locator for address in this
definition?
communication with a peer to be used by the upper
layer protocol. 128 bits. This is used for
pseudo-header checksum computation and connection
[...]
4.2. Renumbering Implications
As stated above, this approach does not target to not make
remove one of the "not" above
communication survive renumbering. However, the fact that a ULID
might be used with a different locator over time open up the
possibility that communication between two ULIDs might continue to
work after one or both of those ULIDs are no longer reachable as
locators, for example due to a renumbering event. This opens up
the
possibility that the ULID (or at least the prefix on which it is
based) is reassigned to another site while it is still being used
(with another locator) for existing communication.
Worst case we could end up with two separate hosts using the same
ULID while both of them are communicating with the same host.
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).
I think this is an overkill.
Which is the probability of this event? i mean, the event is that the
prefix is renumbered and assigned to another site within the lifetime
of an established communication, and then that the same address is
assigned to a host (only this is 2^(-64)) and then that this host
establishes a communication with the same host that the initial one is
communicating...
I wouldn't worry about this case.
[...]
5.4. MTU Implications
Depending on how demultiplexing is handled at the receiver (see
subsequent sections) there may or may not be a need for the shim to
add an extension header to the packets. In some cases such an
extension header would only need to be added to some and not all
data
packets.
This has implications on the MTU that is available to the upper
layer
protocols hence will require some extra handling in the host
implementation. At some level this is similar to the MTU
implementations of IPsec, in that the IP layer would add bytes to
some ULP packets and not others, but in the case of IPsec one would
expect all or no packets in a particular ULP connection to be
affected, whereas in multi6 one some packets, such as those sent
after a locator failure, would be subject to a reduction in the
available MTU.
But, presumably, the MTU change would occur, as you mention, after a
locator failure. This means that a new path will be used after this,
and this, by itself, may imply a change in the available MTU. So, my
point is that the change on the MTU is inherent of the fact that we
are changing the path used for an established communication and not
only due to the addition of an additional extension header.
[...]
7. Assumptions about the DNS
This approach assumes that hosts in multihomed sites have multiple
AAAA records under a single name, in order to allow initial
communication to try all the locators. For multi6 capable hosts,
the
content of those records are the locators (which also serve as
ULIDs).
However, the approach does not assume that all the AAAA records
for a
given name refer to the same host. Instead the context
establishment
allows each host to pass its locators to the peer. This set could
be
either smaller or larger (or neither) than the AAAA record set.
The approach makes no assumption about the reverse tree since the
approach does not use it. However, applications might rely on the
reverse tree whether multi6 is used or not.
7.1. DNS and Centrally Assigned Unique-local Addresses
Earlier we've mentioned that the protocol might provide the basic
mechanism to use Unique-local addresses as ULIDs.
In the cases where hosts have been assigned centrally assigned ULAs
[ULA-CENTRAL], one can potentially take advantage of this to
provide
better support for applications. With centrally assigned ULAs it
is
possible to register them in the reverse DNS tree. As a result,
one
could use the DNS not only for applications which care about
reverse
and forward tree being consistent, but also to find the full set of
locators from the ULID.
But this is the case not only for Centrally assigned ULAs, but for
also for all routable addresses, right?
So i would suggest to move this (very valuable) comment to the
previous section, that makes general observations about the DNS.
8. Protocol Walkthrough
8.1. Initial Context Establishment
Here is the sequence of events when A starts talking to B:
1. A looks up FQDN(B) in the DNS which returns a locator set
which
includes some locators for B. (The set could include locators
for other hosts since e.g., www.example.com might include AAAA
records for multiple hosts.) The application would typically
try to connect using the first locator in the set i.e.,
ULID(B)
= L1(B). The application is prepared to try the other
locators
should the first one fail.
2. The ULP creates "connection" state between ULID(A)=L1(A) and
ULID(B) and sends the first packet down to the IP/multi6 shim
layer on A. L1(A) was picked using regular source address
selection mechanisms.
3. The packet passes through the multi6 layer, which has no state
for ULID(B). A local policy will be used to determine when,
if
at all, to attempt to setup multi6 state with the peer. Until
this state triggers packets pass back and forth between A and
B
as they do in unmodified IPv6 today.
When the policy is triggered, which could be on either A or B,
an initial context establishment takes place. This exchange
might fail should the peer not support the multi6 protocol.
If
I don't understand the usage of the "should" of the last sentence (but
this is probably me)
it succeeds it results in both ends receiving the locator sets
from their respective peer, and the security mechanism
provides
some way to verify these sets.
At this point in time it is possible for the hosts to change
to
a different locator in the set. But until they have exchanged
the locator sets, and probably until they rehome the context
to
i would remove the "probably" in the previous sentence ( i mean, only
after a rehoming they will start using a new locator, right?)
[...]
9.2.1. Flow-label
[...]
Note that we do not yet understand how beneficial it would be to be
able to accept packets from unknown source locators (the rules for
packet injection can probably be more relaxed than for where
packets
i don't understand this sentence... wouldn't it be "reception" rather
than "injection"?
[...]
10. IPSEC INTERACTIONS
As specified, all of ESP, AH, and key management is layered above
the
multi6 layer. Thus they benefit from the stable ULIDs provided
above
the multi6 layer. This means the IPsec security associations are
unaffected by switching locators.
The alternative would be to layer multi6 above IPsec, but that
doesn't seem to provide any benefits and it would add the need to
create different IPsec SAs when the locators change due to
rehoming.
wouldn't be good to refer to the mobike work at this point?