nanog mailing list archives

Re: IPv6 Default Allocation - What size allocation are you giving out


From: Owen DeLong <owen () delong com>
Date: Thu, 9 Oct 2014 13:38:00 -0700


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

On 9 October 2014 22:01, Owen DeLong <owen () 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


Current thread: