Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At an earlier stage I suggested restricting the applicability
of the "However..." sentence to SLAAC [RFC4862]. A short way
of doing this would be

However, the Interface ID of unicast addresses used for
Stateless Address Autoconfiguration [RFC4862] is required
to be 64 bits long.

Regards
   Brian

On 14/02/2017 11:32, David Farmer wrote:
> I have concerns with the following text;
> 
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>    on inter-router point-to-point links. However, the Interface ID of
>    all unicast addresses, except those that start with the binary value
>    000, is required to be 64 bits long.  The rationale for the 64 bit
>    boundary in IPv6 addresses can be found in [RFC7421]
> 
> The third sentence seems to limit exceptions to 64 bit IIDs to exclusively
> addresses that start with binary vale of 000.  There are at least two other
> exceptions from standards track RFCs, that should be more clear accounted
> for in this text.  First is [RFC6164] point-to-point links, as mentioned in
> the previous sentence.  I think the clear intent of [RFC6164] is to allow
> one(1) Bit IIDs for point to point-to-point links using any Global Unicast
> Address, not just those that start with 000.  Second is, [RFC6052], which
> updates [RFC4921] and seems to allow 32 bit IIDs or /96 prefixes for any
> Global Unicast Address when used for IPv4/IPv6 translation, referred to as
> ""Network-Specific Prefix" unique to the organization deploying the address
> translators," in section 2.2 of [RFC6052].
> 
> Thanks.
> 
> On Wed, Feb 1, 2017 at 5:51 PM, The IESG <iesg-secretary@xxxxxxxx> wrote:
> 
>>
>> The IESG has received a request from the IPv6 Maintenance WG (6man) to
>> consider the following document:
>> - 'IP Version 6 Addressing Architecture'
>>   <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@xxxxxxxx mailing lists by 2017-03-01. Exceptionally, comments may be
>> sent to iesg@xxxxxxxx instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This specification defines the addressing architecture of the IP
>>    Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
>>    model, text representations of IPv6 addresses, definition of IPv6
>>    unicast addresses, anycast addresses, and multicast addresses, and an
>>    IPv6 node's required addresses.
>>
>>    This document obsoletes RFC 4291, "IP Version 6 Addressing
>>    Architecture".
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@xxxxxxxx
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@xxxxxxxx
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]