RE: about draft-ietf-multi6-l3shim-00.txt
"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Thu, 27 January 2005 15:51 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Thu, 27 Jan 2005 15:51:55 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: about draft-ietf-multi6-l3shim-00.txt
Date: Thu, 27 Jan 2005 07:51:42 -0800
Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060A0A@xch-nw-27.nw.nos.boeing.com>
Thread-Topic: about draft-ietf-multi6-l3shim-00.txt
Thread-Index: AcUD8sCk1Jw/7PswR9WfxjJBHHMSuQAk2lUw
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: Erik Nordmark <erik.nordmark@sun.com>
Cc: shim6@psg.com
Erik, just a few more nits: page 5: "identifier - an IP layer identifier" seems like a circular definition, especially since "identifier" does not seem to be often used in the text without a qualifying "IP" preceding it. Perhaps, in parallel to the address definition it could say: "IP identifier - an IP layer name for an endpoint (stack name in [NSRG])..." page 5: "NOTE: This proposal does not contain any IP layer identifiers" But it does discuss a number of options. Suggest "NOTE: This proposal does not define any IP layer identifiers, but discusses some options in Section 9." page 7: RFC 3484 is cited but not referenced later page 12: s/multi6 one some packets/multi6 some packets/ page 12: s/packet to big/packet too big/ page 15: s/advise/advice/ page 19: Previously (Sec 2.1) you define X as a malicious host, but then you seem to use host X in a non-malicious context here. Actually, I don't recall where X is malicious within this document, so maybe revise 2.1? Tom > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Wednesday, January 26, 2005 2:01 PM > To: marcelo bagnulo braun > Cc: shim6@psg.com > Subject: Re: about draft-ietf-multi6-l3shim-00.txt > > > > marcelo bagnulo braun wrote: > > Hi Erik, > > > > I think the document is very clear. I have some comments below... > > Thanks for the careful review. > > > I would say that the assumption being made is even > stronger than this. > > In addition to what is stated, there is another assumption > 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) > > That might very well be one way we end up addressing the ingress > filtering and source address relationship, but I don't think > the shim6 > approach necessarily assumes that the source address must affect the > chose exit. If there is a need to be able to explore all > exits (which is > actually a question) i.e. packets transmitted by A to B > should take all > possible exits from A's site, then the source,destination pair of > locators need to be able to cause the different exits. > But depending on the complexity of such solutions we might > decide that > they are not worth-while. > > In any case, I think it is premature to state this as an > assumption of > the form "the source address must affect the exit". > > > > >> 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? > > Yes, that is the easiest edit. It could say "The transport > endpoint is a > function of the transport level, and the transport endpoint > *name* would > typically ..." but that doesn't add much. > > >> 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? > > Well, it is a locator, so I guess it could be either. > FWIW The document tries to use the term "address" very sparingly (and > I'll fix it to be even more careful). The document uses the term > "address field" liberally, but that is not the same as the > "address" term. > > >> 4.2. Renumbering Implications > >> > >> As stated above, this approach does not target to not make > > > > > > remove one of the "not" above > > Oops > > > >> 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. > > I'll edit your text above and add it to the document. > > > > 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. > > I'll also add the above to the document. > > > > >> 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. > > Yes, text needs to be yet more clear on what is ULA specific. > The key point the doc should make is that in some cases consistent > reverse and forward trees for a locator set are hard (such as two > "consumer" ISPs each providing DNS, but no way for the site > to control > what goes in the DNS for the reverse tree). Using centrally assigned > ULAs means that the site can interact with the entity > assigning the ULA > to get consistent reverse DNS. > > > > >> 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) > > English isn't my mother tongue either. I'll reword to use > "if" instead: > "This exchange will fail if the peer does not support the > multi6 protocol." > > >> 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?) > > Well, they might send test packets after they have a locator > set for the > peer, so there would be some difference in the packets they send. > > >> 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"? > > Yes > > > >> 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? > > Would should the document say other than just "[MOBIKE]" > ? > > Erik > > >
- Re: about draft-ietf-multi6-l3shim-00.txt Erik Nordmark
- Re: about draft-ietf-multi6-l3shim-00.txt marcelo bagnulo braun
- about draft-ietf-multi6-l3shim-00.txt marcelo bagnulo braun
- Re: about draft-ietf-multi6-l3shim-00.txt Erik Nordmark
- RE: about draft-ietf-multi6-l3shim-00.txt Henderson, Thomas R
- Re: about draft-ietf-multi6-l3shim-00.txt Kurt Erik Lindqvist