On 2013-05-29 23:27, Jan Boogman wrote: > hmm, this is the ip of our ServiceApp6 SVI interface, which C told us > has only local significance, apparently this is not the case. Time to > renumber then.
Thanks for looking into it! ServiceApp6 is just a next-hop to get your packet into the code that handles the 6rd, thus in the case of traceroute or anything other packet the TTL will be decremented and will thus cause a ICMPv6 Hop Limit for that address to be sent out. Same goes for ServiceApp4 btw. The ServiceApp6 is also visible in a 'show route ipv6' btw. The bigger point with ServiceApp6 though is that it might and likely will originate a ICMPv6 PacketTooBig, this as everything behind it is tunneled and thus has a lower MTU, which is likely only 1280 unless otherwise configured. Thus using a invalid (eg ULA) ServiceApp6 address will just cause providers who do properly filter those addresses and will magically give all kinds of strange connectivity issues. The bigger question becomes why you would use a ULA prefix, when you got a huge block of address space to pick from, which is 'guaranteed' globally unique, in the first place. Next to not having proper filters for not causing such an address to leak of course, along with the upstreams in the path towards it that obviously just accept any kind of address without uRPF checks. The great thing about IPv6 is that typically as a (non-transit) provider one will have only one huge prefix, thus filtering that prefix and dropping anything else with a different source prefix should be extremely easy to do on the edge if it. And such a filter is completely stateless too, thus strange that this is not set up. And as the address is bogus one does not even have to send a response, as it won't go anyway to where it should go. Bottom-line: * enable uRPF everywhere * do source address checks as close to the source (useful if you "cannot" do uRPF on your core router) * Do not use ULA, just use a portion of the huge RIR-assigned prefix you have. Greets, Jeroen
