[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

about draft-ietf-multi6-l3shim-00.txt

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?