Subject: draft-ietf-6man-prefixlen-p2p-00.txt

From: Thomas Narten <[email-masked]>
Date: Sun, 07 Nov 2010 14:29:16 -0500

The document currently says:

   Routers MUST support the assignment of /127 prefixes on point-to-
   point inter-router links.

I fully support this.

However, I believe that as far as routing is concerned, IPv6 continues
to be based on CIDR. There is nothing special about the  64 boundary
from a routing perspective. This, I believe the above should be
changed to the following:

   Routers MUST support the assignment of arbitrary length prefixes
   (including but not limited to /127s) on point-to-point inter-router
   links.

I do not see any reason to restrict implementations to only supporting
/127s prefixes.

Thoughts? In particular, I'd like to hear from operators as to whether
they want the functionality of being able to assign subnets of
arbitrary length, or whether it would be sufficient to only support /127s.

Note: I am quite aware that stateless addr autoconfiguration uses
64-bit Interface Identifiers (IIDs) and that the addressing
architecture says that addresses need to be formed using IIDs. However
these requirements relate to the formation of addresses. I am aware of
no architectural requirement (or justification) that says routing
should only be done on the first 64 bits of an address, regardless of
how an address was formed.

Note: This does not mean I am in favor of or am suggesting any changes
to stateless addr config, or the IPv6 addressing architecture. I
believe the above can be made without changing those documents.

Thomas

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 7 Nov 2010 11:52:01 -0800

> arbitrary length, or whether it would be sufficient to only support /127s.

+ 1 from a network operator.  We don't need handcuffs.

Cameron

---

From: [email-masked]
Date: Sun, 07 Nov 2010 21:05:50 +0100 (CET)

> + 1 from a network operator.  We don't need handcuffs.

+1 from another network operator.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Nov 2010 04:57:33 +0800

> from a routing perspective.

and, to be pedantic but very purposfully specific, a forwarding
perspective

> I'd like to hear from operators as to whether they want the
> functionality of being able to assign subnets of arbitrary length, or
> whether it would be sufficient to only support /127s.

arbitrary, please

randy

---

From: Tore Anderson <[email-masked]>
Date: Sun, 07 Nov 2010 22:02:26 +0100

Hi Thomas,

* Thomas Narten

> However, I believe that as far as routing is concerned, IPv6
> continues to be based on CIDR. There is nothing special about the  64
> boundary from a routing perspective. This, I believe the above should
> be changed to the following:
> 
> I do not see any reason to restrict implementations to only
> supporting /127s prefixes.
> 
> Thoughts? In particular, I'd like to hear from operators as to
> whether they want the functionality of being able to assign subnets
> of arbitrary length, or whether it would be sufficient to only
> support /127s.

I don't see that the draft forbids the use of any other prefix lengths,
it just singles out /127 as the one that MUST be supported.  That makes
a lot of sense, as the (in my opinion) most important reason why the
draft is needed is to close the ping-pong security hole, and /127 is the
only prefix length that does that.

So /127 is the important feature this drafts brings.  Mandating support
for other prefix lengths is, well, feature-creep.  If it doesn't hurt or
delay the process of standardising the /127 part, then sure, why not...

On the other hand, if attempting to mandate support for other prefix
lengths too results in baggage that makes it harder to get the core /127
feature standardised, I'm opposed.  First things first.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Mark Smith <[email-masked]>
Date: Mon, 8 Nov 2010 07:42:10 +1030

Hi Thomas,

On Sun, 07 Nov 2010 14:29:16 -0500

> arbitrary length, or whether it would be sufficient to only support /127s.

if the goal of this draft is to fundamentally mitigate the ND cache
exhaustion issue, by preventing the ping-pong issue when ND NS/NAs are
switched off (as implementations are commonly doing on point-to-point
links), then anything other than a /127 on a point-to-point link won't
prevent the pong-point issue.

> believe the above can be made without changing those documents.

I think the Addressing Architecture RFC would need to be changed, as it
stipulates 64 bit interface ids, which I think implies a maximum of 64
bit prefix lengths, unless these /127s were only permitted within 0::/3
- the impacted text is in 2.5.1 of RFC4291 -

"For all unicast addresses, except those that start with the binary
 value 000, Interface IDs are required to be 64 bits long and to be
 constructed in Modified EUI-64 format."

Regards,
Mark.

---

From: Ben Jencks <[email-masked]>
Date: Sun, 7 Nov 2010 16:56:22 -0500

> arbitrary length, or whether it would be sufficient to only support /127s.

I'd like to hear from a router vendor on the impact of this on TCAM
design. I'm under the (possibly mistaken) impression that frequently
only the first 64 bits are allocated space in the TCAM. If you need to
route on all 128 bits in hardware, it could halve the number of routes
you can carry.

This has probably already been addressed, but I couldn't find it in
the archives.

-Ben

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 08 Nov 2010 01:22:23 -0800

> how an address was formed.

FWIW.

While some implementations of RFC 4861/62 might make assumptions about 
/64 being magic, there isn't anything in those RFCs that specify that it 
is magic. RFC 4862 merely says that the sum of the length of the link 
prefix and the interface identifier needs to be 128.

The IPv6-over-foo documents tend to say that the IID is 64 bits, and we 
have the text in RFC4291. But stateless addr autoconf is actually more 
general than that.

    Erik

---

From: Thomas Narten <[email-masked]>
Date: Mon, 08 Nov 2010 08:24:30 -0500

> prefix and the interface identifier needs to be 128.

Right. That was by design, as I recall. :)

> have the text in RFC4291. But stateless addr autoconf is actually more 

I think "tend to say" is too mild. They all require it, in a MUST
sense, even if they don't use the MUST keyword. Unfortunate, IMO, as
the reality is this will be very hard to change now, given the code
that has already been written. And there is no good reason (IMO) to
require that they be exactly 64 bits long. (The original motivation
for doing so was to leave the door open to approaches like GSE/8+8,
but the reality is that this restriction doesn't seem to have bought
us much, if anything, in practice.)

RFC 2464 (IPv6 over Ethernet) says, for example:

   An IPv6 address prefix used for stateless autoconfiguration [ACONF]
   of an Ethernet interface must have a length of 64 bits.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 8 Nov 2010 12:23:55 -0600

Oh, I am still on US EST time zone and waking up in the middle of the night in Beijing.  Please see in line below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Jencks
Sent: Monday, November 08, 2010 5:56 AM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: draft-ietf-6man-prefixlen-p2p-00.txt

>This has probably already been addressed, but I couldn't find it in

Speaking as a router vendor, the possibly-mistaken-impression is so not the way IPv6 high-end routers silicon works when the router uses a TCAM.  Sorry, I cannot provide any more details on our router implementation, but I can assure this audience that Thomas' belief is correct that IPv6 routing continues to be based on CIDR.

Hemant

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 8 Nov 2010 10:32:42 -0800

Hi Ben,

A TCAM can have an entry which is broader than 64 bits.

An optimization could be to have some entries 64 bits and some 128
bits to be able to more effectively use the TCAM memory based on the
usage.

Thanks,
Vishwas

On Mon, Nov 8, 2010 at 10:23 AM, Hemant Singh (shemant)
<[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 8 Nov 2010 10:40:55 -0800

I agree with Hemant. Speaking as another router vendor, we use CIDR for Ipv6. Routes on all 128-bits are not an issue.

/Olivier

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hemant Singh (shemant)
> Sent: Monday, November 08, 2010 10:24 AM
> To: Ben Jencks; Thomas Narten
> Cc: [email-masked]
> Subject: RE: draft-ietf-6man-prefixlen-p2p-00.txt
> 
> Oh, I am still on US EST time zone and waking up in the middle of the
> night in Beijing.  Please see in line below.
> 
> Speaking as a router vendor, the possibly-mistaken-impression is so not
> the way IPv6 high-end routers silicon works when the router uses a
> TCAM.  Sorry, I cannot provide any more details on our router
> implementation, but I can assure this audience that Thomas' belief is
> correct that IPv6 routing continues to be based on CIDR.
> 
> Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 8 Nov 2010 19:11:17 -0600

Mark,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Smith
Sent: Monday, November 08, 2010 5:12 AM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: draft-ietf-6man-prefixlen-p2p-00.txt

> constructed in Modified EUI-64 format."

Why should any text in RFC 4291 change?  The IID for /127 starts with
binary 000 and only the Modified EUI-64 format has got to deal with the
u/g bits.

Hemant

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Nov 2010 19:08:45 +1030

Hi Hemant,

On Mon, 8 Nov 2010 19:11:17 -0600

> binary 000 and only the Modified EUI-64 format has got to deal with the

I'm pretty sure the leading three 000s referred to are at the start
of the unicast IPv6 address, not at the start of the IID portion.

My assumption has been that this 000s exception is what has
allowed allowed unicast ::1 to be a /128. I think ::1/64 would comply
with the Modified EUI-64 requirement, so the only reason for the
exception that I can think of is to allow the prefix length of ::1
to be /128 instead of /64.

(In the past I've had some uses for multiple loopback addresses within
IPv4 127/8, so I actually wouldn't have minded ::/64 being a loopback
network/subnet, with ::1 the first default IID value for loopback, but
other loopback IIDs allowed. IIRC, ntpd also uses addresses within IPv4
127/4 to represent different local time sources on the local host)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Nov 2010 19:18:36 +1030

On Tue, 9 Nov 2010 19:08:45 +1030

> 127/4 to represent different local time sources on the local host)
  ^^^^^

oops .. 127/8