IPv6 Default Allocation - What size allocation are you giving out

Owen DeLong owen at delong.com
Thu Oct 9 20:38:00 UTC 2014


On Oct 9, 2014, at 1:25 PM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:

> On 9 October 2014 22:01, Owen DeLong <owen at delong.com> wrote:
> 
>>> Why do people assign addresses to point-to-point links at all? You can
>> just
>>> use a host /128 route to the loopback address of the peer. Saves you the
>>> hassle of coming up with new addresses for every link. Same trick works
>> for
>>> IPv4 too.
>>> 
>>> Regards,
>>> 
>>> Baldur
>> 
>> <SARCASM>
>> 
>> And it makes your trace-routes across parallel links oh so easy to
>> identify which of them is at fault for the packet loss, too.
>> 
>> </SARCASM>
>> 
> 
> There are a ton of other technologies with the same problem. Do you never
> use link aggregation? My "parallel links" are all link aggregations, so I
> would not have a way to identify links by traceroute anyway.

Your design problems don’t have to be mine.

Just because you have created that problem through another mechanism doesn’t pose a reason anyone else should accept the same problem in a different circumstance.

> There are a number of good technical reasons to want distinct addresses on
>> point to point links.
>> 
> 
> I am sure there are. Tell me about them.

I gave you one. You decided to dismiss it on the basis of “it wouldn’t help me anyway because I use this other thing that is broken that way regardless.”

Some others (not a conclusive list by any means):
	Having public addresses in trace-routes, ideally with good reverse DNS is actually useful.
	Clarity is almost always an advantage over obscurity when one is troubleshooting something.
	Being able to ping the link address is useful for troubleshooting.
	Being able to source packets from a particular link address can be useful for troubleshooting.

> I am not disputing that there are many reasons to sometimes use link
> addresses. My question is why do you do it by default?


> 
> So far we have heard two arguments:
> 
> 1) You can ping the link address. I assume his equipment will down the
> address if the link is down. My equipment does not do this, I can ping it
> as long it is administrative up no matter link status. So this test is
> useless to me. I am monitoring links by SNMP anyway.

I can’t help that your equipment is ill-behaved at best. Perhaps you should consider alternatives.
I certainly don’t think that designing everyone else’s network to the level of brokenness in your particular environment is particularly valid.

> 
> 2) Parallel links. I don't have many of those, and the ones I have are link
> aggregations. MPLS interferes with this too.
> 
> On the other hand not using link addresses has some advantages:
> 
> 1) You don't need to assign and document them.

Sure you do, it’s just harder. You’re now using essentially an “unnumbered interface” which needs to be documented as such so that people know that when a given loopback shows up, it’s not a unique identifier, but ambiguous across several interfaces.

> 2) It is easy to think about: Router A talks to Router B on link AB. Every
> router has only one address so you don't need to remember which address to
> use.

I don’t have to remember which address to use normally. This is not an advantage.
I can always use the loopback address to talk to a router if my environment is correctly
functioning. If it is not, removing the ambiguity of unnumbered link addresses is more
helpful than being able to use one address for each router while unable to know how
traffic is actually flowing as a result.

> 3) You avoid having a lot of addresses configured on your router.

I don’t see this as an advantage. For a number of reasons (some of which I have expressed above) it is, in fact, a disadvantage.

> 4) You are immune to all the NDP attacks.

No you aren’t. You just change the nature of those attacks.

> 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs
> /124 vs /64. The correct answer is clearly use /128 :-).

Except that it’s clearly an incorrect answer, IMHO.

Owen




More information about the NANOG mailing list