[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-addcon

Gunter Van de Velde (gvandeve) 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 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


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