[arin-ppml] Opposed to 2010-9 and 2010-12
In message <AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.com>, Will
iam Herrin writes:
> On Wed, Oct 13, 2010 at 5:18 PM, Mark Andrews <marka at isc.org> wrote:
> > In message <2376C0DA-2491-40D4-B509-8C643C507A61 at delong.com>, Owen DeLong=
> >> On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:
> >> > If you have a 2 disjoint /16's spead over, multiple pops, then you
> >> > will have 2 6rd prefixes in use both with a IPv4MaskLen of 16. =A0Only
> >> > one of these will be handed out to a specific customer. =A0If you are
> >> > handing out /56's then the 6rdPrefixLen would be 40. =A0Each of these
> >> > 6rd prefixes would be a /40.
> >> For the handful =A0of providers that have only 2 prefixes, that may be.
> >> For the vast majority of providers, the common practice (having more
> >> than a couple of prefixes) is to map the entire IPV4 space onto
> >> a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
> >> prefix for the ISP. Since no ISP has a significant fraction of the
> >> IPv4 space, much of that /24 is wasted.
> > And doing what I suggests works for any number of prefixes.
> In theory, it works for any number of prefixes. So there's this old
> joke I heard:
> What's the difference between theory and practice?
> In theory, there is no difference.
> Preparing and maintaining the configuration for one 6rd prefix is easy
> enough. Two is not so bad. But a hundred? I wouldn't want to be the
> guy stuck with debugging that morass.
> Bill Herrin
Well it can be the same 6rd prefix table into every border router.
The only time one would need to have a different 6rd prefix table
is if the border routeirs didn't support the number of 6rd prefixes
in the table.
Remember you only update the table when you get a new IPv4 prefix
or you get rid of a IPv4 prefix. The table does not need to change
as you move address blocks around internally.
This way any border router can handle any client's traffic. As to
which router handles which clients traffic is then up to which IPv6
routes it announces for enacapsulation or it could just be on the
ingress paths. The decapsulation depends on the addresses in the
DHCPv4 6rd option/web page.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org