Dan, >-----Original Message----- >From: Templin, Fred L >Sent: Tuesday, December 02, 2008 8:18 PM >To: Dan Jen >Cc: RRG >Subject: Re: [rrg] NTP and first packet delivery > >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
I meant "outer_src=RLOC(ITR)"; not "inner_src". >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. Let's forget the bit about "IPv6 ND proxy" for now; I'm not seeing the immediate functional value to warrant the added complexity. Everything else is still good, though. Fred [EMAIL PROTECTED] > >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 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
