Subject: [v6ops] Fwd: draft-ietf-v6ops-3177bis-end-sites WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 24 Oct 2010 18:40:18 -0700

Begin forwarded message:

> From: "George Bonser" <[email-masked]>
> Date: October 24, 2010 1:29:05 PM PDT
> To: "IPv6 operators forum" <[email-masked]>
> Subject: RE: draft-ietf-v6ops-3177bis-end-sites WGLC
> 
> One thing that concerns me is this:
> 
> " RFC3177 suggested that some multihoming approaches (e.g., GSE) might
>   benefit from having a fixed /48 boundary. This no longer appears to
>   be a consideration."
> 
> As long as those approaches keep any smaller assignments out of the
> global routing table, then fine.  It is going to be hard enough for
> dual-stacked operators getting full routes to deal with the explosion of
> /48 routes from PI space that will happen when the current v4 multihomed
> nets start announcing their /48 assignments.
> 
> A v6 route consumes 4x the resources on a router as a v4 route does. 
> A network that is multihomed on v4 will likely also be multihomed on v6.
> A network will likely be multihomed on both protocols at the same time
> initially and for some period after they begin to announce their v6
> assignment.
> 
> Given the above, when the mass migration begins, there will be no
> reduction in the v4 table and an explosion of the v6 table.  Routers are
> going to blow up once the combined table gets to about 500,000 v4 route
> equivalent.  Granted, due to the larger assignments in v6, the migration
> of individual network blocks will not be 1-to-1 in that an end site with
> multiple non-contiguous v4 small assignments can operate with a larger
> v6 aggregate but nevertheless the v4 table will not shrink and the v6
> table will grow.
> 
> I am currently accepting down to a /48 from PI space but not accepting
> nets that small from PA space.  It is going to be pretty hard for folks
> to try to multihome using PA space.  Even if they convince their
> upstream to punch a hole in their aggregate and announce a smaller net,
> getting other people to accept that smaller net is going to be a
> problem.
> 
> In summary, anything smaller than a /48 in PI space is likely to be
> useless if it is announced globally as many will not accept it.
> 
> 
> 
>> -----Original Message-----
>> From: ipv6-ops-bounces+gbonser=[email-masked]
> [mailto:ipv6-
>> ops-bounces+gbonser=[email-masked]] On Behalf Of Fred
> Baker
>> Sent: Sunday, October 24, 2010 11:01 AM
>> To: IPv6 operators forum
>> Subject: draft-ietf-v6ops-3177bis-end-sites WGLC
>> 
>> The IETF IPv6 Operations Working Group is initiating a two week
> working
>> group last call of
>> 
>> http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites
>>  "IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,
>>  Rosalea Roberts
>> 
>> In essence, this is a change to the advice that the IETF gave the RIRs
>> in RFC 3177. We had indicated at that time that we believed that
>> allocating a /48 to each end site was important, for various reasons.
>> We at this point believe that a better model allows the LIR to
> allocate
>> diffrent length prefixes to their customers in accordance with the
>> network's needs.
>> 
>> If you find issues, such as disagreeing with a statement or finding
>> additional issues that need to be addressed, please post your comments
>> to [email-masked].
>> 
>> We are looking specifically for comments on the importance of the
>> document as well as its content. If you have read the document and
>> believe it to be of operational utility, that is also an important
>> comment to make.

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Oct 2010 20:04:04 -0700

>> useless if it is announced globally as many will not accept it.

what people will generally accept is ephemeral.  it once used to be /24
in v4 space.  then it clamped down to /19 except in swamp.  then it
became rir allocation boundaries.  then it became /24 again.  and i
suspect that, within five years, it could be longer than /24.

don't try to hard code it in an rfc.

randy

---

From: "George Bonser" <[email-masked]>
Date: Sun, 24 Oct 2010 20:08:01 -0700

> don't try to hard code it in an rfc.

It will get easier once we see the v4 table begin to shrink but
initially it is going to be difficult while the v4 table undergoes
further fragmentation at the same time those nets are moving to v6.

But I agree, probably not worth hard coding policy in an RFC but I read
it as a recommendation not as a rule.

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Oct 2010 20:31:39 -0700

> further fragmentation at the same time those nets are moving to v6.

ephemeral

> But I agree, probably not worth hard coding policy in an RFC but I
> read it as a recommendation not as a rule.

we should not be saying much at all about policy.  that is the domain of
the ops community, not a technical standards body.  and that is the very
good thing about this draft.

randy