[ppml] PIv6 for legacy holders (/w RSA + efficient use)

[William Herrin]

On 7/31/07, Randy Bush <randy at psg.com> wrote:
> and i really assure you that govt subsidies are not my cup of tea.  but
> i gotta look at what has actually worked.

Nor are subsidies my specialty. Unless someone is willing to step
forward and say, "I think we can induce the creation of subsidies here
in the Americas and here's how," we have to file it along with the
other blue-sky suggestions: interesting but not something that
provides a path to success.


> > by pushing too early, too hard with a mandate to deploy IPv6 inside
> > the Federal government, we've lost support from the bureaucracy.
>
> i have wondered and worried about this.  the gossip i get is that the
> initiative is still moving forward, though maybe not as fast as we might
> like, and more strongly in the military than the civilian areas.  but i
> am as far from dc as one can get in america, geographically and emotionally.

IPv6 deployment is on the priority list of unfunded mandates. That's
the list of mandates which get worked on after all the funded mandates
are either complete or temporarily stalled. Which is to say: very
rarely. Every once in a while there's even a memo reminding the IT
folks that IPv6 deployment is on the priority list of unfunded
mandates and should be taken seriously.


> >> i have no problem with folk getting ipv6 space and looking for a
> >> transit provider.  we were the first provider in the world to offer
> >>  it.  smirk.
> > Then you'll support Scott's "PIv6 for legacy holders with RSA and
> > efficient use" proposal?
>
> dunno how you made this leap to pi, legacy, ...

Scott's proposal is all about folk getting IPv6 space and looking
transit providers. I'd like to see you support it and suggest tweaks
that better refine it towards that goal.


> hmmm.  please explain why pa space from one provider announced to both
> upstreams will not work?  is it some hidden deficiency in the ipv6
> architecture that is not present in ipv4?  'cause it sure works in ipv4.

Each upstream has to announce the precise customer route into the DFZ
regardless of whether its carved from PI or PA space. In IPv4 that's a
/24 because anything longer gets filtered. The route is propagated
through the entire DFZ for it to have the intended effect of allowing
communications from any remote host through either network path. If
you have discovered an ingenious strategy for multihoming without
announcing a customer-specific route short enough that it doesn't get
filtered within the DFZ itself, I'm all ears.

If a multihomed customer has to consume an extra route in the DFZ
anyway, what benefit would motivate us to want to carve that out of
someone's PA space with all the nastiness associated with
administrative management and renumbering? Give them a PI /48 and be
done with it.


By the by, that suggests a way in which a market for IPv4 blocks can
form despite ARIN's efforts to prevent it: A service provider agrees
to provide a /24 for multihoming with a cheap connection such as ISDN
or DSL. The "for multihoming" part is an extra fee. For the extra fee
the customer is permitted to announce the /24 via other providers and
is given a portal where they can instruct the original ISP to either
announce or not announce the route depending on whether the customer
wants to treat the original ISP as a backup link or a primary link.

Good money for the ISP. Good value for the customer who can't justify
an ARIN assignment. Bad news for the size of the DFZ.

This behavior could be blocked by filtering the blocks from which ISPs
receive addresses to /20... But doing so would create the deficiency
you just demanded to see.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004