FW: DISCUSS: draft-ietf-v6ops-addcon

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

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