Re: draft-bourbaki-6man-classless-ipv6-00

[Erik Kline <[e-mail]>]

On 2 June 2017 at 23:56, Job Snijders <[e-mail]> wrote:

> Dear Lorenzo,
>
> On Fri, Jun 02, 2017 at 11:33:41PM +0900, Lorenzo Colitti wrote:
> > Do not support. A few reasons:
> >
> >    - The /64 boundary is beneficial for many reasons. See RFC 7421 and
> RFC 7934.
>
> >From our brief hallway conversation at IETF 98 I was under the
> impression that you have a strong personal preference for the /64
> boundary because you believe there to be '64 bits for the network' and
> '64 bits for the end-user' - however I do not share your (simplistic?)
> view of the world.
>
> Depending on the context, there may be more then 2 parties: an end-user
> might be a network provider themselves, and these functions can be
> recursive. What if someone resells a service to someone else? Without
> flexibility on the /64 boundary one can't cut up the assigned space in
> smaller pieces.
>
> It's been mentioned a couple of times before: any fixed boundary
> (including /64)


The pain one feels when you only get allocated single /64 is actually the
/64 boundary working *for* you.  If a provider /could/ give you less they
would, and we'd be having discussions about only having a single /120 or
even a single /128.


>

is detrimental to permissionless expansion at the edge
> of the network
> >    - The document lists no compelling use cases of what you can do
> >    with less than 2^64 addresses per link than you can't do with a
> >    2^64 addresses per link.
>
> This is not true. The security section for instance shows: "In such
> cases, the use of smaller subnets forces an operational limit on such
> data structures, thus helping mitigate some pathological behaviors (such
> as Neighbor Cache Exhaustion attacks)."
>
> >    - The only technical motivation in this draft seems to be "classful
> >    addressing was a bad idea in IPv4". That's not a valid argument in
> IPv6
> >    because the address space is completely different. A /64 is *four
> billion
> >    times* bigger than the IPv4 internet. That's 10,000 times more than
> the
> >    difference between a grain of sand and the whole planet we live on.
> Such a
> >    huge scaling difference pretty much invalidates any argument that
> solutions
> >    that worked well in IPv4 will work well in IPv6.
>
> Would be a shame to throw away lessons learned from IPv4.
>
> >    - Routing on any prefix length is already required by the standards -
> >    see BCP 198.
>
> Yes, RFC7608 is referenced as suggested reading.
>
> > Please stop trying to make IPv6 be the same as IPv4. That will take
> > away our ability to make the Internet better once IPv4 is gone.
>
> I believe there to be tangible merit in making IPv6 feel and look more
> like IPv4. Perhaps this becomes more apparent when one shifts the
> innovation focus from layer-3 to higher layers.
>
> Making IPv6 look more like IPv4 (for instance through broader adoption
> of DHCPv6 w/ routing options, and classlessness like in IPv4) will
> positively impact IPv6 deployment.
>

Absolutely not.  IPv6 NAT is where is this ends, and that's so asinine in
such a large space it shouldn't bear mentioning.

Kind regards,
>
> Job
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>