Dan, OK to what you said, but I made a couple of conceptual leaps in my last message that might bear a bit more discussion.
As can be told by most of my messages to this list, I am fixated on IPv6 as the inner protocol and IPv4 as the outer protocol. That said, when I said that the ITR and ETR would appear as on-link neighbors, what I meant was that the ETR (on receipt of a packet with inner_src=RLOC(ITR)) can construct an IPv6 link-local ISATAP address of the form: fe80::0200:5efe:RLOC(ITR) and use it as the destination address of an IPv6 ND message such as an RS/RA. The encapsulated ND message would have: inner_src=fe80::0200:5efe:RLOC(ETR) inner_dst=fe80::0200:5efe:RLOC(ITR) outer_src=RLOC(ETR) outer_dst=RLOC(ITR) So, the ITR and ETR get to do an IPv6 RS/RA exchange with each other over the ISATAP link (i.e., the Internet DFZ) and exchange nice information like route information options useful for populating the FIB. If they are smart about it, they can even arrange to use SEND with CGAs so they can each know they are talking to the correct neighbors. Finally, if the DM acts as an IPv6 ND proxy, the ITR could even send an RA as its first packet out to the ETR (via the DM) so the ETR can get an early start on populating its FIB. This just to give a bit more insight as to my thought process. Thanks - Fred [EMAIL PROTECTED] >-----Original Message----- >From: Dan Jen [mailto:[EMAIL PROTECTED] >Sent: Tuesday, December 02, 2008 7:55 PM >To: Templin, Fred L >Cc: Michael R Meisel; RRG >Subject: RE: [rrg] NTP and first packet delivery > >Hi Fred, > >On Tue, 2008-12-02 at 19:35 -0800, Templin, Fred L wrote: >> So, the packet coming in to the DM would have: >> >> inner_src=EID(A) inner_dst=EID(B) >> outer_src=RLOC(ITR) outer_dst=RLOC(DM) >> >> and (after the DM does the mapping lookup) the packet coming >> out of the DM would have: >> >> inner_src=EID(A) inner_dst=EID(B) >> outer_src=RLOC(ITR) outer_src=RLOC(ETR) >> >> In this way, the DM is "off-link" from the viewpoint of the >> ETR, and the ETR gets to perform link-scoped operations (e.g., >> IPv6 ND) with the ITR as if it were an on-link neighbor. Is >> this what you had in mind? >> > >Yes it is, for the reasons you stated. However our current APT design >allows TRs to communicate with the default mappers when necessary(for >failure handling and such). Our recent focus on an incrementally >deployable design from evolutionary principles may cause us to >re-examine these choices though. > >> The alternative is for the DM to decapsulate, perform the >> mapping, then re-encapsulate while injecting its RLOC as >> the outer_src in the transaction, which makes it such that >> the ITR is off-link from the viewpoint of the ETR - not >> so good for link-scoped operations. >> >> I would prefer option A, if that is OK with you. > >Very okay, unless we discover good arguments to do otherwise. Thanks >for putting thought into this! > > >Dan _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
