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