Subject: FW: DISCUSS: draft-ietf-v6ops-addcon

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 5 Jun 2008 09:50:42 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 05, 2008 8:53 AM
To: Gunter Van de Velde (gvandeve); [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 9 Jun 2008 04:49:34 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Gunter Van de Velde (gvandeve)
Sent: Thursday, June 05, 2008 9:51 AM
To: [email-masked]
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.

Brgds,
G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 05, 2008 8:53 AM
To: Gunter Van de Velde (gvandeve); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: DISCUSS: draft-ietf-v6ops-addcon 

Hi Gunter, 

Best regards,
Pasi

---

From: Brian Dickson <[email-masked]>
Date: Mon, 09 Jun 2008 00:34:49 -0400

> Any thoughts? Flames? Screams?

I have several comments regarding both this draft, and how it interacts 
with other RFCs.

Bottom line is, I am in favour of KEEPING the 3.1 and 3.3 sections.

Here's my comments:

Basically, sticking to the notion that only /N where N=64 can be used 
for a prefix length, ignores reality.

Yes, there are people (and networks, some very large) using lots of 
other values of  N, and it benefits the wider
community to document "things that break", "things that work", and such, 
when using N != 64.

IMHO, if there is incompatibility on the part of HBA or CGAs, the defect 
is in the RFCs describing those.
There is nothing *strictly* required for N=64 in the general case for 
CGAs or HBA. The hard-coding of 64 bits
in those RFCs was, IMNSHO, a serious error, placing limitations on its 
use for all cases N != 64.

(Implementations of those RFCs, and those RFCs themselves, would do well 
to add flexibility on values of N.
Yes, it is true, that N=60 may in some sense be slightly weaker than 
N=64. However, if the underlying crypto uses
128 bits in its randomization, which I believe is the case, then exactly 
which N of those bits get used doesn't actually
weaken the predictability. Brute force attacks on crypto only  work 
where the crypto base is small, not where the bits
used from the result of the crypto are small.)

Having actually looked at code for various IPv6 things in popular 
implementations (linux, freebsd, etc.), most of the
places where N=64 is verified, does so by checking N=64 and throwing an 
error. In most cases, if that check were removed,
the code will continue to handle the general case just fine, and the sky 
won't fall.

I agree that placing references to RFCs that have N=64 as prerequisites, 
would be helpful in understanding the impact
of using N != 64.

Brian Dickson

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Jun 2008 14:34:42 +0930

Hi Gunter,

On Mon, 9 Jun 2008 04:49:34 +0200

> 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.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2008 09:01:49 +1200

> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 12 Jun 2008 16:39:08 -0700

At Mon, 9 Jun 2008 04:49:34 +0200,

> Any thoughts? Flames? Screams?

We should keep both of these section.  This is indeed a very confusing
point, and we had a hard time providing reasonable explanation of this
prefix/IFID length issue when we revised the stateless addrconf
document (now published as RFC4862).  The following excerpt from
RFC4862 may help in this context, too.

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.
(from Section 5.5.3)

I know it's still not crystal clear, but it was a best effort
compromise to make the description as consistent with other documents
as a possible, while still respecting existing
implementation/operational experiences and providing greater
flexibility.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.