ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

2017-02-21 21:01:26
On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <job(_at_)ntt(_dot_)net> wrote:

Those "thousands of interconnections" facilitate the communication between
millions of those hosts.


But the configuration cost and management overhead is not proportional to
the hosts that are served by those interconnections, it is proportional to
the number of interconnections. A 10x100G peering interconnection that
serves X million hosts is one interface that has to be managed.

Have you considered that not all interconnections are equal? The type of
interconnection I am mainly (but not exclusively) referring to is the
interconnection between Autonomous Systems to facilitate the exchange of
routing information using BGP-4. Autoconfiguration plays no role here,
everything is configured explicitly. I'd argue that the use case is hardly
comparable with a residential or mobile connection.


Those use cases are very well served by /127 for PNIs and /64s for Internet
exchanges. What's left?

As pointed out in this thread, real networks use all kinds of prefix
lengths. Also, one doesn't renumber everything every time a new document
comes out - you stick to things that work for you.


As discussed above, most links use /64.

Some vendors in this thread have admitted to strive to make things work
with any prefix length, why is there then still a discussion that people
must use /64 - when both vendors and users are not always doing so, for
good reasons?


You're forgetting about host operating system developers and host users,
both of which benefit substantially to having a subnet size that is always
the same and never runs out of addresses.

I'm confident this discussion will eventually resolve itself and conclude
that /64 is not the only valid prefix length, rigid positions rarely are
attainable. Water can flow or it can crash.


Even if you're right, the place to have that discussion is not on this
document.
<Prev in Thread] Current Thread [Next in Thread>