draft-ietf-v6ops-addcon

["Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>]

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?

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