(IPng 4426) /126 or /127 -- neither!
Thu, 18 Sep 1997 12:02:15 -0700 (PDT)
>>>>> "Matt" == Matt Crawford <email@example.com> writes:
Matt> At the PAL1 meeting, when we were considering the 64 bit
Matt> identifier which is now part of the addressing architecture,
Matt> the question arose of teensy little subnets (such as /126's)
Matt> for point-to-point links. I argued at the time that we have
Matt> no place, and need no place, for any prefix with length in
Matt> the range 65 to 127 bits, inclusive.
That is because the address space should be 64 bits in length in the first
place or is there any other reason that escapes me ?
Matt> I'd like to elaborate a bit on this argument. To be
Matt> specific, I'm discussing the case of a point-to-point link
Matt> between two routers under different organizational control.
I don't think p-to-p links within an organization are different.
Matt> A secondary reason is that another address is reserved as an
Matt> ill-defined numeric name for the subnet itself. (I say
Matt> ill-defined because so many implementations treat it as a
Matt> synonym the above broadcast address.) IPv6 uses a similar
Matt> bit-pattern as an anycast address for "any router on this
Matt> What I've seen requested here for IPv6 is a slice of the
Matt> address space to be used for non-routable /126 (or /127)
Matt> prefixes to number point-to-point links.
The two issues aren't really related... one issue is the use of non-routable
addresses for peering, another issue is the question of /127 being valid
subnet lengths. The issue with /127 is as you pointed out if anycast addresses
Matt> This space would
Matt> carry, besides scaling problems, a weighty bureaucracy to
Matt> administer assignments. It should have, therefore, an
Matt> equally weighty justification. I think there is none.
This is an argument against non-routable addresses, which i consider
quite reasonable. The motivation for non-routable addresses btw is
to ease "automatic" renumbering of ASes (which is something of a
very unproven concept).
Matt> The alternative is for each end of a p-p link to be assigned
Matt> an address out of its respective site's prefix.
You mean unnumbered links ? but there are good reasons to have numbered
I don't understand why you are mixing the p-to-p issue with the peering
address issue. What if instead of a serial the peer uses an ethernet ?
Do you proprose to use unnumbered ethernets too ?
Matt> I believe routing protocols can perfectly well handle links whose
Matt> endpoints have unrelated global-scope addresses.
In the context of BGP peering you have:
A ----- B
if link is numbered (global scope address):
A and B will announce routes to each other using as nexthop the global
addresses Ia and Ib (respectivly). Those addresses are the ones annouced
in to the IBGP mesh. I's global prefix will be injected into the IGP.
if the link is unnumbered:
A and B will need to make those annoucements with Ag and Bg. That means
site B needs to manually configure a route to A's prefix and inject it
in it's own IGP a vice-versa.
So, taking the address out of the link only adds complexity and creates
two possible reasons for manual reconfiguration: the renumbering of
site A and the renumbering of site B. While you only had one with
a numbered link: the renumbering of link i.
I'm not claiming that using non-routable addresses on link i is the right
thing to do. I'm just trying to clarify what the potential problem might
be (i'm very tempted to say there is none)...
Matt> RIPng, for example, uses link-local next-hop addresses
Which is a real pain in the neck... because of all the nice effects you
get when you try to redistribute RIP into/from other routing protocols.
But then you need to have link locals anyway in your table (because of
the potential need to send redirects)...
Matt> In summary, the only capability that's lost by having no
Matt> subnet allocated to a p-p link is the ability to address
Matt> "either end of this link."
No. What you loose by not having a subnet in a p-to-p link is the
ability to address the link's end-points knowing only how to route
to the link. That is why numbered links are very useful.
Matt> The cost of providing that
Matt> ability is to either use one of our very large /64 subnets
Matt> per link,
Matt> or to do great violence to the interface
Matt> identifier concept in the new addressing architecture.
Since i've absolutely no idea what interface identifiers are useful for i
cannot comment on that.