Fred, >>> As a first comment, the document is lacking a discussion of the >>> implications of having the BR use its anycast address as the source >>> address for the packets it relays. >>> >>> Take for example the case of two BRs A and B that configure the >>> same IP anycast address, and a CE router C within the 6rd domain. >>> If BR A forwards packets toward C, but the packets are lost in the SP >>> network, any resulting ICMPs could just as easily flow back through >>> BR B instead of A. Then, if the ICMPs don't contain enough information >>> for translation, BR B has no way to send a translated message back >>> to the original source and a black hole can result. >> >> BRs are stateless. it does not matter which one the ICMP comes back to. if >> the ICMP message doesn't >> contain enough of the IPv6 packet there is nothing it can do, regardless of >> which one got the ICMP >> message. the use of the anycast address doesn't change that. > > Then, there needs to be an analysis of the domain of > applicability. For example, a totally stateless 6rd > solution may be incompatible with SP networks in which > there may be ICMP messages that do not return enough > information for translation. > > 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? ;-) 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. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
