Re: Fwd: New Version Notification for draft-farmer-6man-exceptions-64-02.txt

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

David,

In a word, yes. I agree with your points below and your suggestions.

Regards
   Brian Carpenter

"Looks like a disaster; why wasn’t I invited?" - Eeyore (2018)

On 08/08/2018 14:34, David Farmer wrote:
> On Mon, Aug 6, 2018 at 5:32 PM, Brian E Carpenter <
> [e-mail]> wrote:
> 
>> On 03/08/2018 20:38, David Farmer wrote:
>>> On Thu, Aug 2, 2018 at 7:37 PM, Brian E Carpenter <
>>> [e-mail]> wrote:
> 
>  ...
> 
>>> 3) Most radically, I would like to see most of the instances
>>>> of "64" in the text replaced by "N" or "128-N". Along with that,
>>>> there would be a short section saying, basically, "N = 64".
>>>> (And then we could take it out of 4291bis.)
>>>>
>>>> That isn't a backdoor way of attacking /64; I think it would just
>>>> make the whole point clearer, and avoid the possible confusion
>>>> between the two 64s.
>>>>
>>>
>>> I'm not willing to do that in the whole document at least yet.
>> Personally,
>>> I think that "N" or "128-N" and "N=64" is more confusing than 64-bit IIDs
>>> and 64-bit subnets. However, I will use "128-N" and "N=64" in the formal
>>> (normative) operational guidance in section 3. Because I think that will
>>> make the execption for link-type specific documents easier to undersatnd
>> in
>>> that section.
>>
>> And it refers back to the terminology in the non-controversial part
>> of the addressing architecture. I might want to wordsmith this some
>> more, but thanks for taking the point anyway.
>>
> 
> I'll happily accept wordsmithing suggestions.
> 
> But I've worked on it a bit myself already, how about;
> 
> Where N = 64 or the IID length specified in the link-type specific document
> for the link network in question.
> 
> 
>>>> 4) Should we re-insert here the fact lost from RFC2373 and RFC3513
>>>> that only 2000::/3 is currently assigned for global unicast?
>>>> (See https://www.iana.org/assignments/ipv6-unicast-address-
>>>> assignments/ipv6-unicast-address-assignments.xhtml, which still cites
>>>> RFC3513.)
>>>>
>>>> 5) Should we state that "N = 64" only applies to 2000::/3 ?
>>>>
>>>
>>> Note 2 on the top of page 7 of RFC2373 says, "The format prefixes 001
>>> through 111, except for Multicast Addresses (1111 1111), are all required
>>> to have to have 64-bit interface identifiers in EUI-64 format.  See
>> section
>>> 2.5.1 for definitions."
>>>
>>> And, in RFC3513 section 2.5.1 says, "For all unicast addresses, except
>>> those that start with binary value 000, Interface IDs are required to be
>> 64
>>> bits long and to be constructed in Modified EUI-64 format."
>>>
>>> To me they both say all unicast addresses. Now only 2000::/3 has been
>>> released to IANA to allocate to the RIRs, but that is a diffrent issue.
>>> Unicast address beginning with 000 are exceptions, but they are all
>>> special-purpose or otherwise reserved addresses. I talk about all this in
>>> section 2.1.
>>
>> Right. But I'm still a bit bothered by the fact that there is no
>> current standards-track or BCP document that reserves the other /3
>> prefixes. IANA has done the right thing, but that involves citing
>> an obsolete document.
>>
> 
> The IANA considerations section of RFC3513, Note 2 says;
> 
>       For now, IANA should limit its allocation of IPv6 unicast address
>       space to the range of addresses that start with binary value 001.
>       The rest of the global unicast address space (approximately 85% of
>       the IPv6 address space) is reserved for future definition and use,
>       and is not to be assigned by IANA at this time.
> 
> To me that says just that, the rest of the global unicast address space is
> reserved.
> 
> I see the issue that RFC3513 is obsoleted by RFC4291 and this isn't
> included in RFC4291. But personally, I think this is an issue for
> RFC4291bis, this issue should not be tied up in the subnet sizing issues.
> IANA doesn't enforce that anyway.
> 
>>
>> I strongly feel that we should not appear to restrict the prefix
>> length for the other /3s. When they eventually are released for
>> assignment, who knows what they will be used for?
>>
> 
> The status of the currently reserved global unicast address space, as it
> relates to the standard subnet boundary, is an issue that if there is a
> consensus on it, probably belongs in this draft.
> 
> However RFC3587 says;
> 
>    RFC 2374 was the definition of addresses for Format Prefix 001
>    (2000::/3) which is formally made historic by this document.  Even
>    though currently only 2000::/3 is being delegated by the IANA,
>    implementations should not make any assumptions about 2000::/3 being
>    special.  In the future, the IANA might be directed to delegate
>    currently unassigned portions of the IPv6 address space for the
>    purpose of Global Unicast as well.
> 
> So, my view on the status is; since the rest of the global unicast address
> space is reserved the standard subnet boundary does not technically apply
> to it at this time. However, when other reserved blocks are allocated as
> global unicast address space, by default, the standard subnet boundary will
> apply, but we have the option to change things at that time.
> 
> So how about this
> 
> Note: ever since RFC 2373 [RFC2373] addresses with the first three bits 000
> have been an exception to the standard subnet boundary, and addresses with
> the first three bits 001 through 111, except for multicast addresses, have
> been expected to be consistent with the standard 64-bit IID length and the
> standard subnet boundary. However, currently only 2000::/3 has been
> allocated as global unicast address space and released to the IANA for
> distribution to the Regional Internet Registries (RIRs). The applicability
> the standard subnet boundary to future allocations will be determined at
> the time the allocations are release to the IANA. Nevertheless,
> implementations of IPv6 should assume the standard subnet boundary applies
> to future allocations and that 2000::/3 is not special in this reguard.
> 
> 
> But I'd really like to hear from others on this issue too.
> 
>>> 6) A minor point: it's my understanding that some operators
>>>> use slight shorter prefixes than /127 for the RFC6164 scenario
>>>> (router-router links). I don't see any harm in that; is there
>>>> any reason not to relax the text somewhat?
>>>>
>>>
>>> When subnets are configured solely using on-link prefixes, 64-bit on-link
>>> prefixes are recommended, 127-bit prefixes are explicitly allowed, and
>>> other prefix lengths (like 126, 120, or 112) are valid but not
>> recommended.
>>> Implying that there may exist valid reasons in particular circumstances
>>> when other prefix lengths are acceptable or even useful.
>>
>> Which is a perfect example of a normative SHOULD, and that (IMHO)
>> belongs in the main text. The wordsmithing is a bit fiddly.
>> Something like:
>>
>> OLD:
>>       Alternatively, network operators MAY configure point-to-point
>>       router links with 127-bit on-link prefixes, typically by manual
>>       configuration, and no subnet assignment prefix, see RFC 6164
>>       [RFC6164]
>> NEW:
>>       Alternatively, network operators MAY configure point-to-point
>>       router links with specific on-link prefixes, typically by manual
>>       configuration, and no subnet assignment prefix. The on-link
>>       prefix length SHOULD be 127 [RFC6164].
> 
> 
> Ok, now I see what you are getting at. How about;
> 
> Alternatively, network operators MAY configure point-to-point router links
> with on-link prefixes that SHOULD be 127 bits in length, typically by
> manual configuration,
> and with no subnet assignment prefix. See RFC 6164 [RFC6164] Section 6 for
> address selection considerations.
> 
> 
>