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

[Brian E Carpenter <[e-mail]>]

Mark,

I think this thread has shown convincingly that there is a problem with
the current wording of 4291bis about the 64 bit IID length.

I suggest that we wordsmith it on the 6man list and come back to this
broader CC list when we have a proposal.

Regards
   Brian

On 14/01/2017 19:37, Mark Smith wrote:
> 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.
>