ietf
[Top] [All Lists]

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

2017-01-12 15:23:17
Randy,

On Jan 10, 2017, at 5:52 PM, Randy Bush <randy(_at_)psg(_dot_)com> wrote:

1. Section 2.2.3 looks like a complete re-production of RFC 5952, but
I don't see a reference to 5952. Is the intent to deprecate 5952 since
its content is now contained within 4291bis?

5952 has much more very useful detail for those of us who write software
to parse, compare, ... textual representations of ipv6 addresses, see
section 4 of 5952.  so i suggest the replacement of 2.2 with a reference
to 5952.

Per your comment and Brian’s suggestion, I will add a reference to RFC5952.  
RFC5952 doesn’t replace the definitions in RFC4291, it make a recommendation on 
outputting IPv6 text representation, so I don’t think it’s appropriate to 
replace 2.2 with just a reference.


it is very cheering to see section 2.4.0, "96 more bits no magic"
[credit gaurab].

Good


but i am having a hard time reconciling 2.4.4's insistence on a
mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc
6141, widespread operational practice, ...  clue bat please.


This was discussed extensively in 6MAN and resulted in RFC7421 "Analysis of the 
64-bit Boundary in IPv6 Addressing”.  The text in rfc4291bis is:

   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].

Thanks,
Bob