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

Re: draft-ietf-v6ops-addcon



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.

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