Subject: [v6ops] draft-ietf-v6ops-3177bis-end-sites-00.txt

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Oct 2010 13:53:50 -0400

Section 4:
----------

This section seems incomplete in that it does not clearly indicate
that assignment of routing prefixes longer than 64-bits would
violate existing (and several emerging) standards AND that use of 
routing prefixes longer than 64-bits similarly likely would be 
problematic.

	There are a number of active I-Ds headed towards publication
that assume the Routing Prefix is not longer than 64 bits.  It seems
very likely that at least one such I-D would be published, implemented,
and deployed.   

	Further, there is an IAB statement on the desirability of
retaining the 64-bit size for the IPv6 Interface ID:
	<http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html>

	Last, and perhaps most compelling, RFC-4291, Section 2.5.4
explicitly states that Global Unicast IPv6 addresses (that aren't
IPv4-compatible/mapped addresses) have a 64-bit Interface ID field.

At least the IAB statement above and RFC-4291 ought to be cited,
and there should be text in this I-D about the requirement that
unicast routing prefixes not be longer than 64-bits.  That
requirement should be repeated in the summary.

While some might consider this obvious, it is sensible 
to repeat this requirement, especially since that the I-D 
already has Section 4 titled  "Impact on IPv6 Standards"

Section 5: 
-----------

This text in Section 5 can be read in several different ways.
It ought to be edited for clarity.

>       - assigning a longer prefix to an end site, compared with the
>         existing prefixes the end site already has assigned to it, is
>         likely to increase operational costs and complexity for the end
>         site, with insufficient benefit to anyone.

I'm not crystal clear what meaning is intended.
One possible rephrasing of that might be:

	 - If a site already has existing IPv6 routing prefixes assigned to it,
           then it is likely to increase operational costs and complexity for
	   that site, with insufficient benefit to anyone, if a new IPv6 routing
	   prefix with a longer prefix-length is assigned to that site.

If the above is the intended meaning, I'd submit the version
above is more easily read and would eliminate ambiguity.

Also in Section 5:
------------------

If the DFZ RIB/FIB sizes for IPv6 grow at the geometric (exponential ?)
rates seen for IPv4, this creates BGP-related operational complexity.
It also tends to drive up capital costs for operators.

So it seems to me that there ought also to be some mention of the operational 
issues created if either the size of the inter-domain routing table becomes 
unduly large or and the growth rate of the inter-domain routing table becomes 
unduly fast.  Someone other than me can probably phrase this concern more
clearly.  

A citation of the IAB RAWS workshop report might also be relevant 
if such text is added.

Yours,

Ran

---

From: [email-masked]
Date: Mon, 25 Oct 2010 20:25:57 +0200 (CEST)

> very likely that at least one such I-D would be published, implemented,

That may be so - however, prefixes longer than 64 bits are in active
use today, and I see no sign of such use stopping any time soon.

> requirement should be repeated in the summary.

Do you think this is likely to stop people from using prefixes longer
than 64 bits?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Oct 2010 11:51:05 -0700

> that assignment of routing prefixes longer than 64-bits would violate
> existing (and several emerging) standards AND that use of routing
> prefixes longer than 64-bits similarly likely would be problematic.

they darn well better had not be

96 more bits, no magic.  please no magic.

randy

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Oct 2010 15:33:23 -0400

On 25  Oct 2010, at 14:25 , [email-masked] wrote:
> Do you think this is likely to stop people
> from using prefixes longer than 64 bits?

BOTTOM LINE:

It ought to reduce the chance that RIRs and ISPs/LIRs
will delegate prefixes longer than 64 bits to sites.  
That outcome would be very helpful to the recipients 
of such delegated prefixes.

ANALYSIS:

One might wish that RFC-4291, RFC-3513, RFC-2373, and 
other IETF documents covering the IPv6 protocol did not 
specify 64-bits for the Interface ID, but that part of 
the IPv6 specs is now over a decade old -- and widely
implemented in various OSs and (within the IPv6 universe)
also widely deployed.

To quote from RFC-3513, Section 2.5.1, a mere 7 years ago
(& the same text appears in the same section of RFC-4291):

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

There is also operational experience that routing prefixes
longer than 64 bits are problematic in at least some current
IPv6 deployments.  One might wish that were not the case,
but I know of several deployments that have already been
bitten by this.[1]

It would be quite exceptional for an IETF WG to publish
an advice document that discusses some standards issues,
but ignores other standards issues that are also relevant.

Best wishes,

Ran
[email-masked]

[1] Configuring a very long prefix on forming the IP address 
on a point-to-point link between 2 routers seems to work OK, 
according to those reports, provided one doesn't try to advertise 
those very long prefixes in an IPv6-capable routing protocol.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Oct 2010 15:36:14 -0400

> they darn well better had not be

Several network operators have already discovered that
delegating prefixes longer than 64-bits is operationally
problematic.

> 96 more bits, no magic.  please no magic.

Over a decade too late.  

Cheers,

Ran

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2010 21:43:47 +0200

Hi,

> those very long prefixes in an IPv6-capable routing protocol.

OSPFv3 and BGP seem to handle /128 prefixes just fine over here.

Which routing protocol would that be, that one having problems?

Would that be a problem of the *protocol* or just one specific vendor
implementation?

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: [email-masked]
Date: Mon, 25 Oct 2010 22:00:32 +0200 (CEST)

> Would that be a problem of the *protocol* or just one specific vendor

That's what I suspect. We're running IPv6 on Cisco and Juniper gear
here, with /64s, /126s, /127s, /128s and some other prefix lengths,
in IS-IS and BGP. It all works, no problems observed.

---

From: [email-masked]
Date: Mon, 25 Oct 2010 22:01:40 +0200 (CEST)

> > 96 more bits, no magic.  please no magic.

I would claim that trying to legislate prefixes being 64 bits or
shorter only, is over a decade too late.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Oct 2010 22:03:36 +0200

> Would that be a problem of the *protocol* or just one specific vendor

this document is about IPv6 address assignment to end sites.
a prefix longer than /64 would generally not work.
even a single /64 in "general deployments" is problematic (e.g. an IPv6 CE router can take a /64 for it's own internal interfaces), leaving nothing for LAN side interfaces.

I think the IETF should make a general recommendation leading to deployments where end sites are not forced to implement IPv6 NATs. 

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 13:27:33 -0700

> I think the IETF should make a general recommendation leading to deployments where end sites are not forced to implement IPv6 NATs. 

I'm all for that. The issue, of course, that is bringing discussion of NATs is not the traditional uses of NATs (address amplification, topology obfuscation, and prophylactic perimeter security, each of which is unnecessary given IPv6 or bogus on its face), but of scaling routing. As I said to someone else on another list we're both on not too long ago, "if you want to tell us how to scalably manage O(10^7) IPv6 PI prefixes without translation, without rearranging all of the operator's transit contracts (which would be one of the side-effects of Metro Addressing), and without aggregation, I guess I'm all ears." This is the flip side of the point that Tony, Marla, and Jason were making in the draft they discussed recently, and were very loudly told that the operational community was going to do what it was going to do, and that meant that multihoming means PI addressing.

---

From: [email-masked]
Date: Mon, 25 Oct 2010 22:45:18 +0200 (CEST)

> of such delegated prefixes.

As of today, if I had a customer connecting to my network on a real
point-to-point link (SDH, serial, etc), I would assign a /127 prefix
for this link - and expect the customer use this prefix. I could be
convinced to assign a /64 but then I'd have to require the customer
to actually *use* a /127. This is because a /127 is (IMHO) the only
reasonable way of preventing a loop on such links.

In my mind there is a definite difference between assignment and use.
For my residential customers I would assign a /56 (using DHCP-PD). I'm
fine with an RFC saying that longer than /64 should not be assigned
to such customers. Trying to legislate against the *usage* of longer
than /64 is simply wrong - and many years too late.

> 	to be 64 bits long and to be constructed in Modified 

That's fine. There is no *enforcement* of this paragraph unless you
really ask for it - which means that there are quite a few addresses 
in use out there which don't follow the modified EUI-64 format.

> but I know of several deployments that have already been

Since routing prefixes longer than 64 bits are in reasonably wide use,
I'd expect such implementations to be fixed, in order to survive.

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Oct 2010 07:28:54 +1030

> shorter only, is over a decade too late.

So you don't consider published RFCs "legislation"?

I'm never comfortable with the approach of "it works so it must be
right". The only reason it is working might be just that you've been
lucky. Luck isn't reliable.* Things working by design are always going
to be more reliable than things that work by luck.

Regards,
Mark.

(* Apparently you can run a four stroke engine on two stroke fuel - I'm
not sure for how long - the guy who said he did it didn't say - but
since it is working, does that make it right? _Luckily_ he only did it
for a short time so he probably didn't damage anything.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2010 11:05:07 +1300

> reasonable way of preventing a loop on such links.

The draft talks about assignments to sites, not to point to point
links. I think we've hammered out consensus that /127 is just fine
for pt2pt links.

Sites won't work properly today with prefixes longer than 64 bits,
because sites use SLAAC by default. If 3177bis doesn't point that
out, it should do.

    Brian

---

From: [email-masked]
Date: Tue, 26 Oct 2010 00:17:44 +0200 (CEST)

> because sites use SLAAC by default. If 3177bis doesn't point that

Agreed, /64 or shorter should be assigned to sites. We assign /56 to
residential customers, and /48 or /56 to business customers.

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Oct 2010 09:13:01 +0900

> will delegate prefixes longer than 64 bits to sites.  

and it will reduce the probablity of comets impacting on an ietf
meeting.

can we focus on reality here?

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Oct 2010 09:14:04 +0900

> here, with /64s, /126s, /127s, /128s and some other prefix lengths, in
> IS-IS and BGP. It all works, no problems observed.

and i would not touch a vendor who could not do so.  so we know of such
vendors?  time for attitude adjustment time.

randy

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2010 10:34:37 +0300 (EEST)

> vendors?  time for attitude adjustment time.

FWIW, some time ago a customer reported a forwarding loop problem on 
their equipment which seemed to have been caused by an Extreme 
Networks device when configured w/ >64b prefix.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Oct 2010 16:41:26 +0900

>> and i would not touch a vendor who could not do so.  so we know of
>> such vendors?  time for attitude adjustment time.
> 

great.  was a bug report filed?  until fixed, will avoid broken vendor.

randy

---

From: Olen Stokes <[email-masked]>
Date: Wed, 27 Oct 2010 11:45:13 -0700

The latest EXOS code release corrects reported customer problems.  Please see EXOS release documentation for additional information about support for IPv6 routes with masks > 64 bits.

In keeping with today's email about "Etiquette", I would be happy to take any additional discussion offline.

Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Wednesday, October 27, 2010 3:41 AM
To: Pekka Savola
Cc: v6ops mailing list
Subject: Re: [v6ops] draft-ietf-v6ops-3177bis-end-sites-00.txt

randy
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops