TJ wrote:
-----Original Message-----
From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
boun...@puck.nether.net] On Behalf Of David Freedman
And what, prey tell is wrong with "/126 on point to point links", you want
to use SLAAC between routers?

Nothing is wrong, per se.  It certainly works.  Oh, and I don't believe I
said anything about SLAAC.
However, there have been numerous conversations back and forth, on many
sides of this.

My feeling is based on two things:
I don't like the idea of vendors/providers ignoring an RFC just because. And note the RFC in question leaves no wiggle room here.
                If a different solution is better, codify it in a draft, get
community consensus and get it ratified in a RFC.
        Not saying the IETF is always right, but I'd prefer any such
disagreement gets vetted by as many eyes as possible.
                In this case there are lots of things that assume 64bits of
host space - most aren't relevant to PtP links, but still ...
Aggregation
        IMHO the most efficient solution is to burn one of the client's /64s
on the client-facing link ... one covering prefix for entire client, including CPE.

IIRC there was some chatter about using /127s (again), dumping the subnet
router anycast address (for security reasons, I believe).
        I'd have the same thing to say to that conversation - get some loose
consensus pre-implementation.

Lots of folks, myself included use /112 for point to point links, server
only subnets and just about anything that doesn't require RA's (which is
almost everything in a hosting environment).  /112 is a convenient
bit boundary to work with and one size fits all (p-p and multipoint)
applications.

In closing, I guess I would turn it around and say "provide me a "really
good reason" to not use /64s as dictated" ...

Making it difficult for autoconf to work on certain subnets is a big
plus.

- Kevin
_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to