(1) Unless it was changed when I wasn't looking, there is a
rule in the IPv6 architecture that says that one cannot
subnet on a prefix longer than a /64. That rule appears to
be someone hostile to efficient use of address space at the
"small network with subnets" side of things. Has that rule
outlived its usefulness? If so, how do we go about changing
it before IPv6 is sufficiently widely deployed to make it
even more difficult and disruptive to do so?
Perhaps you could define the term subnet?
I don't see how such an architectural limitation can be enforced. There is no
way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they
choose.
Perhaps not, but such an ISP might incur significant support costs. For
instance, an ISP that assigned a /128 might get a complaint every time a
customer tried to change his computer or network card. That, and
several IPv6 protocols were designed with the assumption that /64 was
the maximum length of a prefix to be assigned to a net. There aren't
any more bits in those protocols to support a longer subnet mask.
Realistically if an ISP wanted to restrict its customers to a maximum of
one IPv6 host there are probably less disruptive (therefore cheaper)
ways to do this than to try to make the customer's network prefix be a
/128. And then the customers would just NAT, and the ISP's effort would
be wasted. So there's little benefit to the ISP in doing this,
particularly if they can get enough addresses from their upstream
providers or registries.
More broadly, IETF can't prevent an ISP from offering a service that
claims to be Internet but doesn't follow the specified protocols. But
since those protocols are the agreements by which interoperability is
obtained, an ISP that violates those protocols risks alienating its
customers when their applications do not work. In practice, ISPs do
this routinely (e.g. ISPs that provide DNS servers that lie about the
RRs for a given zone), and they also get pushback for doing so.
Customers are slow to learn but some of them do change ISPs when they
find out that they're being screwed.
As you point out, we have very little power to prevent ISPs (or
equipment vendors, or OS vendors, or users) from doing harm. But that
doesn't mean we should say that it's okay for them to do things that we
have every reason to believe will do harm.
I agree, encoding authorization data into the network address is not a good
strategy, another structural oddity is that we continue to view the Internet
as a network of hosts rather than a network of services.
Well, at one level, it is a network of hosts. The network of services
is built on top of the network of hosts. It's just that the boundary
between the two is fuzzy.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf