Ole, > -----Original Message----- > From: Ole Troan [mailto:[email protected]] On Behalf Of Ole Troan > Sent: Monday, February 22, 2010 3:13 PM > To: Templin, Fred L > Cc: softwires; DHC WG > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > Fred, > > >>> If the BRs were allowed to keep a small amount of state, > >>> however, then they would be able to return appropriate > >>> ICMPs to the IPv6 host on the outside even if the ICMPs > >>> coming from the SP network on the inside did not include > >>> enough information. Provided, that is, that the ICMPs > >>> within the SP network are returned to the correct BR. > >>> That is where a unicast source address instead of an > >>> anycast one would steer the ICMPs to the correct BR. > >> > >> you are suggesting that a router should store a copy of every IPv6 header > >> plus IP tunnel header > for > >> _every_ packet it forwards? and it should do this at wire-speed? > >> how much do you want to pay for this box? ;-) > > > > No; that's not what I'm suggesting. I am suggesting that > > for only those CEs for which ICMP unreachables are being > > received that the BR store an MTU value and a reachable > > flag. Then, when new packets come in from an outside IPv6 > > host, the BR can drop the packet and return an ICMP if the > > packet would violate the MTU or if the CE has recently been > > known to be unreachable. > > > >> are you talking about pre-RFC1812 IPv4 routers? in that case you wouldn't > >> have enough information > to > >> correlate that accurately with the stored IPv6 packet in any case. > > > > The BR does not need to know anything beyond the minimum > > 8 bytes in the ICMP; all it needs to know is whether the > > CE is reachable, whether there is an MTU limitation on > > the path, etc. Then, it can return suitable unreachables > > or PTBs to the source host. > > sure, section 9.1 refers to how path MTU discovery is done for the tunnel. > with the description in > section 3.2.2 of rfc4213. sure, if you use PMTUD on a tunnel then if you use > anycast SA on the BRs, > the MTU cache would have to be populated on both.
I could not parse "populated on both" - which do you mean by "both"? I assume the BR A is one of the both, but what is the other? BR B? (If so, it is only BR A and not BR B that needs to maintain state if A uses its unicast address instead of the anycast.) Also, this is not just about PMTUD; it is about any unreachable that may come from the SP network (e.g., host unreachable, protocol unreachable, etc.). > I know you are doing a heroic effort with MTU issues in the Internet, but I > feel we have been through > most of the MTU discussions already during the discussions on previous > revisions of the document. do > you feel we need to rehash them again? The larger MTU discussion should be taken up on a different thread. Fred [email protected] > cheers, > Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
