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 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? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
