Re: Review of draft-ietf-6man-rfc4291bis-06

[Mark Smith <[e-mail]>]

On 14 Jan. 2017 15:36, "David Farmer" <[e-mail]> wrote:



On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter <
[e-mail]> wrote:

> ....
>
>
> Which is exactly why we have so far only delegated 1/8 of the
> IPv6 address space for global unicast allocation, leaving a *lot*
> of space for fixing our mistakes. Moving away from /64 as the
> recommended subnet size might, or might not, prove to be necessary in
> the long term future. That's why the point about routing being
> classless is fundamental. I do think we need to be a bit more
> precise on this point in 4291bis.
>
>     Brian
>

Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and
I'm fine with that, but that's not what the following says.

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421
<https://tools.ietf.org/html/rfc7421>].


It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an
Imperative as discussed in section 6 of RFC2119.

I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support
that and believe it to be the consensus of the IETF. Maybe even explicitly
noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support
by SLACC.  But it is not correct to say the /64 is REQUIRED.


I don't think /127s should really be recommended either.

They don't guarantee that the ping pong problem is solved, because it
depends on both ends being configured with the /127 prefix length by the
operator or operators at each end if the link. There is no protocol
requirement that both ends of a link have the same prefix and prefix
length, nor is there any protocol checking of that condition.

For example, if an ISP configures a /127 on their end of the customer's
link, but the customer just configures a default route on their end over
the link, it is a legitimate configuration by the protocols, Internet
access will work (so the customer might assume the link is configured
correctly), and yet the link is vulnerable to a ping pong attach despite it
"having" a /127 prefix.

So it is a mitigation, however it relies on the operator or operators being
disciplined about the configuration, and comes at the cost of other things
that may be useful if a 64 bit IID was available e.g. protect against
discovery of link addresses via unsolicited inbound probing if the IIDs are
random (which may include static configuration of an offline generated
random 64 bit IID).

Regards,
Mark.


I also believe RFC7608 supports this conclusion.

Thanks.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

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