Subject: IPv6 Prefix Length Recommendation for Routing Protocols (draft-boucadair-6man-prefix-routing-reco)

From: <[email-masked]>
Date: Thu, 26 Jun 2014 13:16:12 +0000

Dear all,

We submitted a short draft that calls explicitly for a recommendation to unlink routing/forwarding and IPv6 prefix semantic.

The draft is available at:
https://datatracker.ietf.org/doc/draft-boucadair-6man-prefix-routing-reco/?include_text=1

6man Working Group                                          M. Boucadair
Internet-Draft                                            France Telecom
Intended status: Standards Track                             A. Petrescu
Expires: December 28, 2014                                     CEA, LIST
                                                           June 26, 2014

        IPv6 Prefix Length Recommendation for Routing Protocols
              draft-boucadair-6man-prefix-routing-reco-01

Abstract

   The length of IP prefixes to be manipulated by forwarding and routing
   processes is policy-based; no maximum length must be assumed by
   design.  This document sketches a recommendation to be followed by
   forwarding and routing designs with regards to the prefix length.
   The aim is to avoid hard-coded routing and forwarding designs that
   exclude some IP prefix lengths.

Comments are more welcome.

Cheers,
Med

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 26 Jun 2014 13:59:11 +0000

Mohamed, Alexander,

I like the idea of your I-D.

Some quick comments if you do not mind:

  *   the paragraph about prefix length of 0, does not bring any added value IMHO
  *   In the recommendation:
     *   Minor comment: the 64-bit boundary is for SLAAC-enabled medium not only for end-user prefix assignments :-)
     *   More seriously, and while working for a vendor, please note that I am not a HW designer of any kind!, requesting routers not to restrict to any length (including longer than /64) can have either a performance impact (such as double look-up 64-bit by 64-bit) or a huge $$$ and kW/h cost. May I suggest to amend the text by adding any prefix length between 0 and 64 (full performance) and 128 (with perhaps a performance hit)?
     *   When I read your text, I am confused by the 'routing protocols' (BGP, OSPF which obviously do not care about prefix length — except for number of entries in RIB) and 'forwarding' (which is probably FIB = HW where the prefix length has an impact — see above). May I suggest to split the discussion into two parts? Or restrict it to forwarding?

En espérant vous aider :)

-éric

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: jeudi 26 juin 2014 15:16
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: IPv6 Prefix Length Recommendation for Routing Protocols (draft-boucadair-6man-prefix-routing-reco)

Dear all,

Abstract

Cheers,
Med

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Jun 2014 12:20:14 -0400

I do not see a need for this document.  It is a re-statement of CIDR.  Why?

Regards,
Brian

On 6/26/14 9:16 AM, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Jun 2014 06:39:17 +0900

> More seriously, and while working for a vendor, please note that I am
> not a HW designer of any kind!, requesting routers not to restrict to
> any length (including longer than /64) can have either a performance
> impact (such as double look-up 64-bit by 64-bit) or a huge $$$ and
> kW/h cost. May I suggest to amend the text by adding any prefix length
> between 0 and 64 (full performance) and 128 (with perhaps a
> performance hit)?

details of performance assumptions of cover-the-v6-rfp-check-mark vendor
implementations are not needed or helpful.  we hope that some day
vendors will support ipv6 as a first class citizen.

randy

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 26 Jun 2014 22:05:06 +0000

Hmm.
>    It is fundamental to not link routing and forwarding to the IPv6
>    prefix/address semantic [RFC4291].  This document includes a
>    recommendation for that aim.

Is that anything like “The IPv6 prefix in [RFC4291] is a CIDR prefix, and should be treated accordingly; the 64 bit prefix length is not a “class” in the sense of RFC 791 addresses, but an addressing convention useful to [SLAAC].”?

My private opinion, which is just that - an opinion - is that address formats such as described on RFC 4291 are an artifact of the LAN technologies that they apply to. Instead of extending a 48 bit MAC address to 64 bits on Ethernet and using a 64 bit IID on LANs that use a 64 bit MAC address, I might have suggested using a 48 bit IID on an Ethernet and a 64 bit IID on other LANs when appropriate. It’s not like we mix MAC address lengths on the same LAN.

And then there’s the question of privacy addresses. Again, the privacy address should be 128-n bits long, where n is the length of the LAN’s prefix announced in the RA.

But I’m obviously an appropriate person to burn at the stake, and the working group is much wiser than I am.

> 2.  Recommendation
> 
>    Forwarding and routing protocols MUST NOT restrict by design the
>    length of IPv6 prefixes.  In particular, forwarding and routing
>    processes MUST be designed to accept prefixes of any length up to
>    /128, by increments of 1.

See above on CIDR. 

>    Certain lookup algorithm implementations (find the prefix matching a
>    given destination address) may be affected by this recommentation,
>    and more so in IPv6 than in IPv4.  Some implementations may prove
>    less well performing when prefix lengths are above 64 (e.g. see
>    discussion by F.  Baker and 6MAN WG members at http://www.ietf.org/
>    mail-archive/web/ipv6/current/msg20633.html)

Two issues with the statement.

1) F Baker is a member of 6man as much as anyone else is. If you want to point to a thread, I suggest you point to a thread.

2) more to the point, I might suggest you point to commonly used chips such as Broadcom’s that limit operational deployability by making this assumption, rather than to ephemeral email threads.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 26 Jun 2014 22:33:33 +0000

Randy

	> vendors will support ipv6 as a first class citizen.

If you do not mind a direct, non-educated reply, then I will add "when
customers will be ready to pay for IPv6 as a first class citizen?"

Joke/irony on the side, you and I and many many others (individuals,
customers, vendors) want to have IPv6 because it is the only way forward
for all of us and all Internet users. And, again with a lack of HW
expertise (my electronics examination is still a nightmare for me), I am
afraid that physics does not care about the usefulness/need of IPv6... If
a chip needs ??? times more gates to process a prefix length of 120 bits
at wire speed than a <= 64 prefix length (again a guess), then there is
not choice but adding more gates, i.e. more $$$ and more kW/h.

I would hope so much that cost does not care... Then I would really love
to have any prefix size being forwarded at the same speed on all Internet
routers... BTW, this would require to have _ALL_ residential CPE to have a
128-bit x86 processor.

-éric-the-dumb-engineer

PS: I hate to write as a simple engineer from a vendor, but, let's be
honest... On BOTH sides
PS2: I do not know where [email-masked] has been nicknamed as "IPv6
Deployment Prevention <[email-masked]>" ;-)

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Jun 2014 07:37:03 +0900

> 2) more to the point, I might suggest you point to commonly used chips
> such as Broadcom’s that limit operational deployability by making this
> assumption, rather than to ephemeral email threads.

i have sympathy for your feeling stung.  but as an operator, i hope
broadcom's limitiations, like other vendors', will also be ephemeral.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Jun 2014 07:46:49 +0900

> customers will be ready to pay for IPv6 as a first class citizen?"

in the late '90s, when no vendor supported ipv6, we deployed a multi-
continent parallel frelling network, yes circuits, using bsd and kame
code (of which our lab was a key developer (remember itojun)) to deliver
ipv6 to customers.  so you are telling the wrong folk to put money where
ipv6 mouth is.

we waited years for even half-assed dual-stack support from vendors.

so excuse if i take crying on shoulders as more like biting. :)

randy

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 26 Jun 2014 15:52:59 -0700

>> customers will be ready to pay for IPv6 as a first class citizen?"

Various vendors have been charging EXTRA for the magical "IPv6 enabling
license" on their products for almost a decade already.

Indeed, time that that becomes a default option and not only an extra addon.

> so excuse if i take crying on shoulders as more like biting. :)

Thank you Randy for stating what needs to be stated.

Welcome to 2014 people of the IPv6 list!

Native IPv6 deployment has been happen for more than 15 years now, with
and without the help of the "larger" vendors.

IPv6 inclusiveness was one of the many reasons why quite a few people
moved to Vendor J a decade ago...

Greets,
 Jeroen

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 26 Jun 2014 23:02:23 +0000

>we waited years for even half-assed dual-stack support from vendors.

Back in the early 2000... And some vendors were earlier than others... Now
all vendors are mostly ready, waiting for customers ;-) (sorry could not
help but writing this)

>so excuse if i take crying on shoulders as more like biting. :)

Back to yesterday or the day before (I am not a soccer fan...)

-éric-looking-forward-for-US-vs-Belgium :-)

---

From: Steven Blake <[email-masked]>
Date: Thu, 26 Jun 2014 22:17:39 -0400

On Thu, 2014-06-26 at 13:16 +0000, [email-masked] wrote:
> Dear all,
> 
>  
> 
> We submitted a short draft that calls explicitly for a recommendation
> to unlink routing/forwarding and IPv6 prefix semantic. 

[snip]

What problem is this draft trying to solve?

// Steve

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Jun 2014 14:21:01 +0900

> What problem is this draft trying to solve?

a whack-a-mole that keeps saying /64 is special for things other than
slaac.

notice a number of ops folk all like it.  we hit the excuses and
confusion more often than you may imagine.

conversely, what is it that bothers you about it?

randy

---

From: [email-masked]
Date: Fri, 27 Jun 2014 10:32:17 +0200 (CEST)

> a whack-a-mole that keeps saying /64 is special for things other than

For instance, we've had people claiming that CIDR was only meant to 
apply to the first 64 bits.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jun 2014 14:52:54 +0200

Hi Eric,

Thanks for the reply.

>   * the paragraph about prefix length of 0, does not bring any added

The intention was to be explicit about the corner cases of the prefix 
length (0, 1, 127, 128).

It is true that the meaning 'default route' implied by a prefix length 0 
has not much impact on the recommendation that routing and forwarding 
happens on arbitrary prefix length values.  As such that paragraph could 
be eliminated.

>   * In the recommendation:
>       o Minor comment: the 64-bit boundary is for SLAAC-enabled medium
>         not only for end-user prefix assignments :-)

I would add that whereas it is for SLAAC-enabled media, it is only for 
the IEEE kind of such media.  SLAAC per se works with arbitrary prefix 
lengths, including non-64.  (and I dont have an example of a non-IEEE 
SLAAC media which is not /64).

>       o More seriously, and while working for a vendor, please note that
>         I am not a HW designer of any kind!, requesting routers not to
>         restrict to any length (including longer than /64) can have
>         either a performance impact (such as double look-up 64-bit by
>         64-bit) or a huge $$$ and kW/h cost. May I suggest to amend the
>         text by adding any prefix length between 0 and 64 (full
>         performance) and 128 (with perhaps a performance hit)?

I think this is feasible to amend the text in that sense.  But we would 
need the right text.

>       o When I read your text, I am confused by the 'routing protocols'
>         (BGP, OSPF which obviously do not care about prefix length —
>         except for number of entries in RIB) and 'forwarding' (which is
>         probably FIB = HW where the prefix length has an impact — see
>         above). May I suggest to split the discussion into two parts? Or
>         restrict it to forwarding?

I agree that the most important part of the intention of this draft is 
what you call forwarding.

In the routing protocols part  - right, they are not caring about prefix 
length; they'd typically have prefix length fields containing any  value.

However, there may be some doubts.  E.g. in OSPFv2 packet formats there 
is some form of 64-bit padding, which is obviously not 128bit padding. 
(search "64 bits" in RFC5340).

Maybe other such 64 limitations exist in OSPF and BGP.

Alex

> From: "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Subject: IPv6 Prefix Length Recommendation for Routing Protocols
> (draft-boucadair-6man-prefix-routing-reco)
>
>     Dear all,
>
>     We submitted a short draft that calls explicitly for a
>     recommendation to unlink routing/forwarding and IPv6 prefix semantic.
>
>                                                                 June 26,
>     2014

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jun 2014 14:56:06 +0200

Le 27/06/2014 00:05, Fred Baker (fred) a écrit :
[...]
>> Certain lookup algorithm implementations (find the prefix matching
>> a given destination address) may be affected by this
>> recommentation, and more so in IPv6 than in IPv4.  Some
>> implementations may prove less well performing when prefix lengths
>> are above 64 ([...] 6MAN WG members
>> at http://www.ietf.org/
> 1) If you want to point to a thread, I suggest you point to a thread.

Yes, sorry, it was just a sort of reminder.

> 2) more to the point, I might suggest you point to commonly used
> chips such as Broadcom’s that limit operational deployability by
> making this assumption, rather than to ephemeral email threads.

I will look find a reference as example.

Alex

> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 27 Jun 2014 13:35:01 +0000

>(search "64 bits" in RFC5340).

I was not aware of this specific issue for OSPFv3 (assuming you meant v3
and not v2 :-))

-éric

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jun 2014 15:44:14 +0200

Hi Eric,

I meant v3 indeed.  I was not aware of it either.  I just opened the RFC 
and looked for "64".  Maybe it is nothing.

Alex

---

From: Steven Blake <[email-masked]>
Date: Fri, 27 Jun 2014 14:08:05 -0400

> conversely, what is it that bothers you about it?

I would like to think that I can now and forever get a /64 for each of
my LANs.   Every time this topic comes up someone proposes to redesign
SLAAC to allow IID < 64 bits.

Regards,

// Steve

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 27 Jun 2014 20:04:16 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Steven Blake

> SLAAC to allow IID < 64 bits.

Aren't the two unrelated?

I would like to think that if I get a /64 from an ISP, as many people do, I can create any number of subnets in my home or small office network, without breaking everything, and without having to use NAT.

And I would also like to pretend that the rhetoric about the gargantuan address space in IPv6 is remotely true.

But it's obvious why operators like /64, so I'm not unaware of the simplicity factor. Still, let's not forget that until the IETF says otherwise, this is still just a measure to be used for a small subset of the IPv6 address space (12.5 percent), which in principle could be changed in the future if necessary.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jun 2014 08:52:00 +1200

> apply to the first 64 bits.

Not to mention specific evidence that some products do not
behave correctly for some >64 prefix lengths - see earlier
discussions on the why64 draft.

Logically, this draft is not necessary. Practically, it is,
as a clarification for confused product designers.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Jun 2014 08:42:00 +1000

In message <[email-masked].
> Aren't the two unrelated?

No.  You can do DHCPv6 or static.
 
> I would like to think that if I get a /64 from an ISP, as many people do, I c
> an create any number of subnets in my home or small office network, without b
> reaking everything, and without having to use NAT.

I would like to think that ISP's would stop being stupid and actually
supply something bigger than a /64.  There has *never* been a good
reason to just supply just a /64 to a customer.  All the address
assignment policies to ISP's assume customers will get more than
/64's.  Usually in the /48 to /56 range.  ISP's that only supply a
/64 are not living up to their end of the bargain.

	* 6RD doesn't force /64's.  It's ISP idiocy that leads to /64 with 6rd.
	* 6to4 does /48 by default.
	* PD doesn't force /64's.

Tunnel brokers hand out more than /64's for nothing

	HE hands out /48's on request.  Just click the button.

If you have broken equipment that can't hand out or accept arbitary
length prefixes it should be replaced.

> But it's obvious why operators like /64, so I'm not unaware of the simplicity
>  factor. Still, let's not forget that until the IETF says otherwise, this is 
> still just a measure to be used for a small subset of the IPv6 address space 
> (12.5 percent), which in principle could be changed in the future if necessar
> y.

Handing out a /56 is just as simple as handing out /64.  Be that
with PD, 6rd or static.  Just request the correct amount of space
from your RIR.  ISP's should punishing their customers for their
failure to properly plan.

ISP's are expected to be experts.  Customer's arn't.  Leave customers
with all /64 subnets and twiddle the bits at the ISP end not the
other way around.  It's not like ISP's aren't twiddling bits with
IPv4 anyway.
 
Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Jun 2014 21:38:37 +0900

> apply to the first 64 bits.

some of them had to have tla and nla clawed out of their cold dead
hands.

randy