Randy, > On Jan 10, 2017, at 5:52 PM, Randy Bush <randy@xxxxxxx> 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