Re: draft-ietf-v6ops-addcon

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-06-09 17:04, Mark Smith wrote:
> Hi Gunter,
> 
> On Mon, 9 Jun 2008 04:49:34 +0200
> "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> wrote:
> 
>> Folks,
>>
>> The question here is if different then /64 prefix considerations should
>> be given?
>>
>> At the moment any prefix NOT starting with '000' must have a 64bit
>> network ID.
>> The addcon draft documents items that 'if' one has to divert from this 
>> recommendation (against any IETF doc) to at least be aware of other 
>> restrictions regarding anycast, etc....
>>
>> Now at IESG review that is contested, and the editors are trying to 
>> understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
>> should 
>> be removed or not?
>>
>> I think it is good content as reality seems to indicate that people DO
>> use 
>> different then /64 prefix addresses.
>>
>> Any thoughts? Flames? Screams?
>>
> 
> I think there is value keeping it in there. If IPv6 will work with
> longer than /64 prefixes in certain cases (e.g. when not using CGAs,
> etc.), I think there's value in advising people of what issues they'll
> encounter or need to avoid, should they choose not to stick to /64s.
> Choosing whether to have non-/64s, contrary to the RFCs, seems to me to
> be very much an Addressing Consideration.

I agree. This is an Informational document so it should contain all
relevant information. It might be worth being extra clear that
this is not recommended practice, but since there are phrases like
"An allocation of a prefix shorter then 64 bits to a node or interface
is considered bad practice." and
"this kind of address conservation is of little benefit ..."
seem pretty clear to me.

    Brian
> 
> Regards,
> Mark.
> 
>> G/
>>
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
>> Behalf Of Gunter Van de Velde (gvandeve)
>> Sent: Thursday, June 05, 2008 9:51 AM
>> To: v6ops@ops.ietf.org
>> Subject: FW: DISCUSS: draft-ietf-v6ops-addcon 
>>
>> Hi All,
>>
>> During IESG review an interresting comment appeared regarding different
>> then /64 addresses and would like to understand if the WG has some
>> opinion before 'removing' section 3.1 and 3.3.
>>
>> See context of the Comment below.
>>
>> Brgds,
>> G/
>>
>> -----Original Message-----
>> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
>> Sent: Thursday, June 05, 2008 8:53 AM
>> To: Gunter Van de Velde (gvandeve); iesg@ietf.org
>> Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
>> Subject: RE: DISCUSS: draft-ietf-v6ops-addcon 
>>
>> Hi Gunter, 
>>
>>> GV> Maybe an extra sentence should be added here to make this crystal 
>>> GV> clear? What about the following:
>>>
>>> GV> CHANGED TO:
>>> GV> Based on RFC4291 it is legal for any IPv6 unicast address starting
>>> GV> with binary address '000' to have a subnet prefix larger than, 
>>> GV> smaller than or equal to 64 bits. Each of these three options is 
>>> GV> discussed in this document. This document mainly considers global 
>>> GV> addresses (assigned from RIR/LIR) and ULAs and while neither of 
>>> GV> these address types start with binary "000"
>>> GV> only /64 prefixes are allowed on these types of addresses.
>>>
>>> GV> Is the above an acceptable solution? 
>> If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
>> addresses they do apply to?
>>
>> (In particular, the discussion doesn't seem relevant for IPv4-Compatible
>> or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
>> Loopback Address. And this kind of detailed advice doesn't seem
>> appropriate for some future, not-yet-defined addresses, whose properties
>> we don't really know yet.)
>>
>> If the intent is simply to describe how to use prefixes other than
>> /64 with global addresses -- which I know some folks are doing -- then
>> this document needs have "Updates: RFC 4291" on cover page, and be
>> explicit about changing the "MUST" in RFC 4291. (And obviously, there
>> needs to be rough IETF consensus to make this change.)
>>
>>> Section 6 should say that using subnet prefixes other than /64 breaks 
>>> security mechanisms such as Cryptographically Generated Addresses
>>> (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 
>>> to use protocols that depend on them.
>>>
>>> GV> It is indicated in Section 3. that these mechanisms are broken. 
>> The text that was added to Section 3 does not mention CGAs or HBAs.
>> Also, it should be in Section 6, as the current text there ("This
>> document doesn't add any new security considerations...") is incorrect.
>>
>> Best regards,
>> Pasi
>>
>>
> 
>