IPv6 Addressing Question

[Eric Vyncke (evyncke)]

For your information, Michael (in cc) and I wrote an IETF draft presenting the pros and cons of this approach:

 http://tools.ietf.org/html/draft-ietf-opsec-lla-only-03

Comments are welcome

From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Mike Jones
Sent: samedi 6 avril 2013 13:15
To: Sander Steffann
Cc: IPv6 operators forum
Subject: Re: IPv6 Addressing Question

On 6 April 2013 11:30, Sander Steffann <sander at steffann.nl<mailto:sander at steffann.nl>> wrote:
Hi Mike,

> IPv6 routing protocols seem in some cases to exclusively use automatic link local addresses. Even for manual configuration, link locals deal with the ND exhaustion attack problem in the core quite nicely, while also simplifying address management.
>
> Are there practical reasons for global addresses on router interfaces?
Pinging interface endpoints for debugging and monitoring, being able to see which interface is used in a traceroute, stuff like that. Routing protocols can work perfectly fine without global addresses, but netadmins have a harder time with just link locals :-)  But true: it is something that I have tested in the lab, and it does reduce the attack surface of the network a bit.

Cheers,
Sander

Hi,

Is it actually that useful to see 50% entered london from nyc on interface nyc1-0.lon2.core and 50% on nyc1-1.lon2.core? I believe in theory the egress interface is theoretically shown in traceroute which would be useful if that actually happened, but i'm not sure the ingress interface you see in practice is as useful once the packet has reached that hop?

Although I see your point about being able to ping eth3-0.lon2.core and eth3-1.lon2.core from nyc and have each point to a specific link to check them independently. I had considered that if you were testing this link you would do it from nyc using eg fe80::2%lon1, however doing that without logging in to the router is useful.

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130406/76b7a1f6/attachment.htm>