Re: [v6ops] A good example of why we need to careful about ULAs

[Brian E Carpenter <[e-mail]>]

On 31/05/2013 10:07, Jeroen Massar wrote:
> On 2013-05-30 14:45, Brian E Carpenter wrote:
> [..]
>>> In the early news, not really a new problem.
>>>
>>> RFC1918 and 100.64/10 leak too, 
>> In traceroutes, link-locals sometimes leak too.
> 
> I have never come across that; except maybe when tracerouting to a
> link-local, and then, that would only be one hop anyway.
> 
> If you know how to replicate it, I am very interested in a packet dump
> or what is involved to cause it.

I understand it happens when the router in question has a next-hop
that is link-local and it has been set to use that address as the
default source address for ICMP replies, *and* there is no source address
filter along the path that blocks it.

This is not new; there's a thread starting at:
http://www.ietf.org/mail-archive/web/v6ops/current/msg11277.html

>> All these are confusing and make the traceroute hard to interpret,
>> but they don't actually *matter*. What matters is if they leak in
>> actual traffic such as attempted TCP connections. Does that happen?
> 
> One should only see a link-local when:
>  - the source packet is link-local
>  - the destination host only has a link-local and replies (TTL or so)
> 
> But that should never cross more than one (1) hop as link-locals should
> not be forwarded.

True, although in the specific case of traceroute you get a bit of useful
information from the illegal forwarding (whether it's link-local or ULA).

    Brian
> 
> Greets,
>  Jeroen
> 
> .
>