6PE mapped addresses used for ICMPv6 responses - knob to fix that?

[Darrell Newcomb]

On Jun 10, 2013, at 3:04 PM, David Farmer wrote:

> On 6/1/13 01:46 , Tore Anderson wrote:
>> * Jeroen Massar
>> 
>>> That is, if you have 6PE (IPv4 LSP) in your network routers might send
>>> an ICMPv6 message from the IPv6-Mapped-IPv4 address.
>>> 
>>> And as :::ffff:0.0.0.0/96 should not be in anybody's BGP table, it will
>>> fail uRPF.
>>> 
>>> Is anybody aware of a knob that can force for instance the loopback
>>> address to be used on these boxes?
>> 
>> AIUI, the P routers in a network using 6PE might not have IPv6 addresses
>> on them at all, not even on the loopback interface. If that's the case,
>> there are three options that I can see:
>> 
>> 1) enable core hiding, or
>> 2) don't emit ICMPv6 errors at all, or
>> 3) use an IPv4-mapped address as the source of the ICMPv6 errors.
>> 
>> All of these constitute ways of breaking traceroute, although only #3
>> has a slight chance of actually relaying some useful information back to
>> the person performing the traceroute. So IMHO it's the best option.
>> 
>> Tore
> 
> I don't think any vendor does this, but what about assigning a different local prefix to use for IPv4-mapped IPv6 addresses, instead of the well-known ::ffff:0.0.0.0/96.  You wouldn't be able to automatically know its a IPv4-mapped IPv6 addresses, but in this case I'm not sure that is really needed.  This would have the added benefit that reverse IPv6 DNS just works, even if the IPv4 address is RFC 1918 or otherwise not routed.  Also, in the case of 6PE I'm not sure you would even need to provide a working return path either.
> 
> An example would be 2001:DB8:1234:5678:0:ffff:0.0.0.0/96.
> 
> Anyone see a fundamental problem with something like this?

No problem other than the normal complexity of having the intermediate device be able to generate replies and then the software/configuration capability of defining the address.  And that can be a pretty big assumption and not at all easy across a diverse set of boxes.


But generically having real IPv4 addresses/subnets mapped into a /9x has been quite a favorite technique of mine.  Typically the only real hurdle I've seen in the numerous networks that's been used is having involved technical staff over-estimate their ability to do the translation rather than using supplied tools..... the human error rate can be daunting.  ;-)   

Of course there is FIB packing and ACL depth-of-match issues in some equipment types to watch out for.  Or IOS some devices get really bad really fast, but that's a potential risk for lengths greater than the assumed /64 length or for any large prefix count internal network and are distinct from IPv4 mapping (just that the mapping might be the trigger for longer prefix lengths).   There have also been imagined challenges with compatibility in some equipment; like /30 vs. /31 rejection by equipment in IPv4 there might be an element of truth to that, but every case I've tried to get someone to walk me through hasn't actually been shown to be a real failure for /12x subnets.  Oh how we humans see patterns for things that don't really exist ... I'm just as guilty of it myself until reminding one-self that you really don't *know* what you think you might.  :-D