Ebalard, Arnaud wrote: > Hi, > > Le 7 juin 07 à 01:31, Tony Hain a écrit : > > > There is no 'amplification', so the abstract is just wrong. > No, you are wrong. At least, read that : > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html >
I read it around the time it was sent, and it says that you were able to reflect the same packet back multiple times. That does not amplify it to multiple destinations as the current document claims, or amplify the amount of bits in flight at any given time. > > The best this can do is route a single stream around policy; > Again, wrong. It is still a single stream, and your assumption about policy is that a packet should traverse a single link at most once. As I said, it routes a single stream around policy. > > > and for some the ability to route around the brokenness of an ISP > > in anti-competitive mode is a value, not a drawback. > Can you point us to the tool/device you are using to do that. > > > The crap in the document about an anycast destination being > > an amplification shows how little understanding > And your sentence little reading of the document. I will admit I only read it through once, and given the overall agitation over the hysteria related to this topic I likely missed subtle points. That said, this entire effort is about preventing opportunities, there is nothing that is new and the same mitigation that is done for IPv4 routing headers works here. > > > Anycast == 'unicast to the nearest instance' > RH0 mechanism allows people to bypass that. It still only goes to the 'nearest instance', just the one closest to the RH0 target rather than the source. That is not an amplification, it is bypassing local policy. > > > again I say the hysteria needs to stop. > True > > > There is no reason to preclude nodes from processing RH0 packets. > > If you > > have to say something say that 'hosts must not forward' else they > > become > > routers. [...] > Already said. *BSD did it wrong, but that's just a tiny part of the > whole story. So we are in the mode of changing specs when an implementation got it wrong??? If MSFT had been the one, wouldn't the response be screaming about how clueless they are about following specs? A device that forwards L3 packets not addressed to itself is a router. If a device is not expected to forward packets, it must drop RH0 packets where the next hop is other than self. Since RH0 processing in the host is about dealing with ingress filtering to reach an alternate address, and we now have mobility to do that, I have no problem with removing the ability for a host to process a received RH0 packet. I do have a problem with trying to kill it outright because that precludes a metro/geo aggregation environment where the source needs to select transit across the local exchange fabric. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
