Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines

Sent from my iPad

On 2012-08-09, at 5:58 PM, Philip Matthews <philip_matthews@magma.ca> wrote:

> 
> On 2012-08-09, at 17:39 , Mark ZZZ Smith wrote:
> 
>> Hi Michael,
>> 
>> 
>> ----- Original Message -----
>>> From: Michael Behringer (mbehring) <mbehring@cisco.com>
>>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>>> Cc: Philip Matthews <philip_matthews@magma.ca>; Gert Doering <gert@space.net>; "sthaug@nethelp.no" <sthaug@nethelp.no>; Eric Vyncke (evyncke) <evyncke@cisco.com>; "v6ops@ietf.org list" <v6ops@ietf.org>
>>> Sent: Thursday, 9 August 2012 9:08 PM
>>> Subject: RE: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines
>>> 
>>>>> Traceroute would work for you,
>>>> 
>>>> It shouldn't, because intermediate routers should discard ICMPv6 
>>> packets
>>>> with LL source addresses, according to RFC 4291 section 2.5.6.
>>>> 
>>>> The fact that they don't is an implementation error, and we 
>>> shouldn't rely
>>>> on that. ICMPv6 should never be sourced from a LL address.
>>> 
>>> I can confirm that at least one implementation (ours) responds using a global 
>>> address (from a loopback), not the link local. 
>>> 
>>>> 
>>>>     Brian
>>>> 
>>>> however outside of your network, other people would be querying their
>>>> own version of 0.8.e.f.ip6.arpa., hiding your interface and router names.
>>>> This idea might be useful to assist with troubleshooting for a "Using 
>>> Only
>>>> Link-Local Addressing Inside an
>>>> IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01 
>>>> scenario.
>>> 
>>> The concern is that for ICMP echo reply, traceroute, etc the router will respond 
>>> with a global address, which is a loopback address (in the absence of global 
>>> addresses on the interface). You can therefore see the router, but not the 
>>> interface (unless RFC5837 is implemented, which is generally not the case 
>>> today). 
>>> 
>>> So I can't see how this helps troubleshooting? (I must be misunderstanding 
>>> something here)
>> 
>> As Brian said, traceroute won't reliably work due to the LL source address issue, however having unique static LL addresses across your network's router interfaces, and then having a record of the static LL address assignments in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for supplementary information) might still be a useful troubleshooting tool. For example, if you're on the CLI of one router, and want to find out the interface name corresponding to an adjacent router's static LL address, a ping command with a reverse resolve of the address far router's interface address would return the result of the PTR and therefore the name of the remote interface and router.
> 
> I believe traceroute will work.  As Michael said, at least some routers, if there is no GUA/ULA configured on the interface, then the router sends the ICMP reply using the IP address of the loopback or system address as the source address. Michael confirmed that Cisco routers work this way, and I can confirm that Alcatel-Lucent routers work this way. 
> 
> If anyone knows of a router which behaves differently, I would be interested in hearing of it. This would be a useful comment to put in my I-D.

If you do put that point in, should it be noted that it is a "de facto" behavior of [some] routers?  ( I don't recall a rule suggesting this is the official behavior). 

I guess it's possible to not configure a loopback on a router (although it would seem strange not to have one).  I guess it's also possible that the LB may also not be in the same routing instance.

Also, some operators limit the reachability of the LB from outside their administrative perimeter for security reasons since it's used for management and routing functions (which does not always apply to the interface IP addresses).

Regards,

Victor K

> 
> - Philip
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops