[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initial issues
> * This started off a thread in private about what
> the address assignment policy for v6 should be. Randy noted also that
> the IESG has asked for a revision to §2.5.6 of
> draft-ietf-ipngwg-addr-arch-v3-04.txt to make it classless rather
> than clasful. In other words, the multihoming environment for v6
> is going to be identical to v4, viz. CIDR. TLA/NLA will no longer exist.
By removing the boundary, levels of ISPs are also removed.
So, all ISPs must be toplevel wasting global routing table or
singlly homed to another ISP.
Just as we have a fixed boundary for subscribers at /48 for multihoming,
we need a fixed boundary for ISPs somewhere for multihomed next level
> Wording change for multihoming: "introducing prefixes visible within
> at least two ASes" is a simplistic definition. One might want to
> look at various narrowings of the definition of AS in that over time,
> but solviing that problem is a current issue.
It is merely that introduction of ASes and AS numbers makes the problem
worse. It can be avoided by totally removing the idea of ASes and just
rely only on prefixes.
A logical consequence of "introducing prefixes visible within at least
two ASes" is "introducing prefixes visible within many ASes" and
is "making prefixes independent to ASes", which means ASes are now
However, as prefixes can still (and should) have fixed boundaries,
CIDR has nothing to do with it.
And, the fundamental problem of multihoming is still there.
> We currently handle ~10**5 in a shaky fashion, and alot of those
> prefixes are a combination of Toxic Waste Dump, swamp, and aggregation
> entropy. According to Vijay Gill, the last is the biggest current
> contributor, rather than multihoming.
It is true that, until just recently, the Internet was not large
enough or the swamp was so deep that the scalability problem of
multihoming was not easily observable.
But, it does not mean that the problem does not exsit nor is
disappearing. Instead, it is appealing.
> That is to say, v6-CIDR does not introduce any new IDR technology scaling
> issues beyond an increase in the total number of prefixes.
V6-CIDR does not solve any old IDR technology scaling issues including
an increase in the total number of prefixes.
> So, carrying on from here, I suggest that the wg can spend some
> time initially getting v6-CIDR right, by fine-tuning the BCP and
> other v4-CIDR material. This would be productive, particularly if
> the address people can get sensible guidelines for the allocation
> of v6 addresses.
Once v6 addresses are widely allocated without multihoming issues
solved, it is as bad as v4 ones and we need another version of IP
with uncontaminated address space for scalable multihoming.
> Given that v6 has hooks for magical (re-)numbering, it would be
> interesting to explore how they should work inside a set of v6
> routers and hosts which are suddenly multihomed to a new entity,
> or de-homed from one of 'n' entities.
An irony is that outside the inner circle of v6, no one believes
in the magic.
> v6-renumbering work should
> be pressed to focus on this particular problem,
In the real world, that's a meaningless statement.