Subject: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix

From: [email-masked]
Date: Wed, 11 Feb 2015 04:47:01 -0800

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 11 Feb 2015 13:35:54 +0000

> A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

I agree with the sentiment of this document but as an observation,
unrestricted longest-prefix-match lookup tends to be circumvented by
vendors in order to provide increased forwarding table capacity.  There's a
curious practical example in the "Cisco Nexus 5000 Series Configuration
Limits" document:

Dynamic routes		16,384 (includes IPv4 and IPv6 routes)
V6 LPM routes		128 entries

It would be interesting to see why the difference between v4 and v6 lpm
lookup entries is greater than 4x.

Otherwise, I support this doc.

Nick

---

From: Rick Casarez <[email-masked]>
Date: Thu, 12 Feb 2015 08:56:41 -0500

I know I have run into vendors who have optimized their data structures for
/64 but not for anything smaller. We are already pushing them on that front
to do it for all prefix-lengths.

I support this document.

-------------------
Cheers, Rick

Experiences not things.

On Wed, Feb 11, 2015 at 8:35 AM, Nick Hilliard <[email-masked]> wrote:

> > A new draft has been posted, at
> http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a
> look at it and comment.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 15:59:43 -0800

I don't believe we should dictate routing table sizes. We can state that it
must be possible to route on prefix levels up to /128, but we cannot state
how many entries the hardware must support.

Because /64 is a common maximum prefix length, it makes sense to treat
64-bit routing entries and 128-bit routing entries differently in hardware.

Reality dictates that routing on 128 bits consumes more resources than
routing on 64 bits. Attempting to enforce that all routing table entries
must be full 128 bits wide will either result in the hardware supporting
fewer routing table entries or in the hardware costing more, neither of
which to anyone's gain.

So, for example, if a given router did not support /123-bit long entries at
all, then that would not fit in this best practice. But if the router
supported 1024 /128 entries and 64k /64 entries, I think that would comply.

On Thu, Feb 12, 2015 at 5:56 AM, Rick Casarez <[email-masked]>
wrote:

> I know I have run into vendors who have optimized their data structures
> for /64 but not for anything smaller. We are already pushing them on that
> front to do it for all prefix-lengths.
>
> I support this document.
>
> -------------------
> Cheers, Rick
>
> Experiences not things.
>

---

From: David Farmer <[email-masked]>
Date: Fri, 13 Feb 2015 02:45:57 -0600

> On Feb 11, 2015, at 04:47, [email-masked] wrote:
> 

I support the draft.  However, I have some suggested improvements for the current text.

1.  I'm worried as phrased, section 1, paragraph 3 could be misinterpreted as implying a /64 is a valid end-site prefix.

    A detailed analysis of the 64-bit boundary in IPv6 addressing 
    together with the implication for end-site prefix assignment are 
    documented in [RFC7421], but no recommendation is included 
    in that document.

Maybe just eliminate "together with the implication for end-site prefix assignment", I'm not sure it's necessary or adds much to this discussion to talk about end-site prefix assignments anyway.  However, then the only thing the paragraph says beyond what is in the first paragraph is "but no recommendation is included in that document."  So, how about just deleting this paragraph altogether and adding a version of that idea to the end of the first paragraph, maybe something like this;

    However, such a recommendation was out of scope for that document.

2.  I'd like to see the evolution of the IPv6 Addressing Architecture discussed and used as part of the argument too.  How about the following added as the second paragraph of section 1;

    As discussed in [RFC7421], "the notion of a /64 boundary in the 
    address was introduced after the initial design of IPv6, following a 
    period when it was expected to be at /80." This evolution of the IPv6 
    Addressing Architecture, resulting in [RFC4921], and followed with the 
    addition of /127 prefixes for point-to-point links in [RFC6164], clearly 
    demonstrates the intent for future IPv6 protocol developments to have 
    the flexibility to change this part of the architecture when necessary 
    and justified. 

3.  I think the first paragraph of section 2 would be clearer if it said;

    IPv6 implementations MUST...

4.  The last paragraph of section 2 makes me think of the scene from Star Wars where Obi-Wan uses the Jedi mind trick on the storm troopers saying, "these aren't the droids you're looking for."

   This recommendation does not conflict with the 64-bit boundary for 
   some IPv6 stateless address autoconfiguration (SLAAC, [RFC4864]) 
   based schemes such as [RFC2464].

Why doesn't it conflict?  Just because we said so?  How about something like this instead;

   This recommendation might seem to conflict with with the 64-bit 
   boundary for some IPv6 stateless address autoconfiguration (SLAAC,
   [RFC4864]) based schemes such as [RFC2464].  However, [RFC7421] 
   clarifies this is only a parameter in the SLAAC process and using 
   DHCPv6 [RFC3315] or manual configuration other longer prefix lengths 
   are in operational use. 

But does this paragraph even belong in this section?  Maybe move it up into section 1, as well as providing reasons why it does conflict.  How about making this the second paragraph and #2 above the third paragraph of section 1.

5.  Maybe additional informative references to RFC4942 and draft-ietf-opsec-v6 would in order for the security considerations section.  Only referencing RFC4291's security considerations, which says the following, seems really kind of wimpy by today's standards.

    IPv6 addressing documents do not have any direct impact on Internet
    infrastructure security. Authentication of IPv6 packets is defined 
    in [AUTH]. 

(AUTH = RFC 2402)

How about;

    This document does not introduce security issues in addition to what 
    is discussed in [RFC4291].  Overall IPv6 security issues are more 
    completely discussed in [RFC4942] and [draft-ietf-opsec-v6].

Thanks

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 09:15:27 +0000

Dear David,

Thank you for these comments.

I’m OK with almost all your edits.

A new revision with these changes will be available very soon.

Thank you.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de David Farmer
Envoyé : vendredi 13 février 2015 09:46
À : [email-masked]
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix

On Feb 11, 2015, at 04:47, [email-masked]<mailto:[email-masked]> wrote:
A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

    in that document.

    and justified.

   are in operational use.

    in [AUTH].

(AUTH = RFC 2402)

How about;

    is discussed in [RFC4291<https://tools.ietf.org/html/rfc4291>].  Overall IPv6 security issues are more

Thanks

David Farmer                          Email: [email-masked]<mailto:[email-masked]>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Feb 2015 11:52:58 +0000

> fewer routing table entries or in the hardware costing more, neither of

the concern people have is that if you end up with hardware which
effectively dictates /64 due to lpm optimisation constraints, this will
make it really troublesome to use other prefix lengths.  This might or
might not be ok for individual boxes with a couple of connected /64s, but
once you link this into a routing domain it can cause serious trouble.

E.g. in the case of the N5K previously quoted, 16k ipv4 entries makes it a
fine box for certain types of ipv4 edge deployment, but the limit of 128
longest prefix match entries for ipv6 means that it's impossible to hook
this into an ipv6 IGP routing domain, which means that from a generic ipv6
l3 deployment point of view, the box is nearly useless.

>From this point of view, it may be useful to have an RFC to say to vendors
"please don't do this because it is actively harmful".

Otherwise everyone acknowledges that there is a balance to be drawn between
cost and scalability.  Maybe this balance could be made more explicit in
the draft.

Nick