[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [GLOBAL-V6] Comments on AP Consensus
[consolidated multiple posts]
> Xavier Henner wrote:
> IMHO, there's no real problem for very large compagny.
> Cisco and other multinationnal compagnies have the size (in number
> of end-users site) of a little ISP.
> The main problem is for little and medium organizations which are
> IPv4 multihomed.
Agree. Because these are a large part of the market and if ipv6 does not provide what they currently have in v4 they'll never make the move.
> Imaging a hosting compagny. 2 upstreams, an ASN, a /21 (IPv4),
> which is aggregated in only one upstream's routing table.
> This is possible in IPv4. Tomorrow, IPv6.
> The same organization don't need more than a /48.
> So what ? We give a sTLA ?
Have a look at [MHAP]
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
We should not be using "sTLA" anymore, should we?
> Craig A. Huegen wrote
> Okay, done rambling. All of this is meant to demonstrate that
> those dedicated to beating enterprises and other end-sites into
> submission in the quest for 8,192 maximum DFZ routing entries will
> stunt the IPv6 Internet's growth.
I beg to differ. The other side of this coin is that if v6 ends up being the same routing mess as v4 currently is, there is little incentive moving to it.
> John L Crain wrote:
> To me the thinking behind this seems to indicate addressing/routing
> based on geography.
Definitely.
> Unless someone has a way to make routing work based on
> continent/country/city borders rather than topological based on
> ISP's border routers I don't see how this will work.
Look at [MHAP]
> Wilfried Woeber wrote:
> Fact is that we do NOT want an end site to apply for an (s)TLA.
True, although it is crystal clear that would-be multihomers would do anything to have xTLA status because they want their prefix in the DFZ's routing table.
> Just one more thing, talking about multi-homing: one of the BIG
> differences in V6 (compared to V4) is that a TCP session can
> easily survive a layer 3 re-route, because the source and
> destination address remain the same.
With a connection opened to a PA address and the provider associated with that PI crashes?
> Trying to do redundancy with multiple addresses on both ends has
> the potential to get us back to the X.25 ages: the TCP session
> breaks, some sort of RESET. Which means that the application has
> to get involved. Unless we can come up with some clever abstraction
> for identifying source and destination for a TCP (or V/AE2TP *)
> connection...
Have a look at [MHAP].
> Local Internet Registry in the IPv4 world translates to local to a
> specific network. This is generally some form of Internet Service
> Provider, be it a commercial organization, the NOC of a large company
> or an Educational institution.
Understood. The point I was trying to make is this: _when_ geographical/local PI addresses are used, we will need to find a name for the authority or registry that assigns them. The logic of semantics says that if a "RIR" is what assigns regional PI addresses, a "LIR" would be the logical name of who assigns local PI addresses. Therefore, there _might_ be some value in keeping "LIR" for future use and find another term for "IPS performing registry functions". Again, this is a matter of pure semantics, not policy.
> I do believe there have been Internet Drafts on geographically
> based addressing schemes though. Not sure of the ID's names though?
There are several ones, and I do not think the actual addressing scheme is that important, but the mechanism that makes it possible is.
>> - LIR : city / metropolitan area.
> Carlos Friacas wrote:
> Local... any place, any country.
Yes.
>> I brought this issue regarding the dissapearance of "TLA". It's a
>> matter of semantics, but I think that you should not call an
>> operator or ISP a "registry".
> Im afraid this is the current model in Europe... and it seems it
> has been working fine.
The model is fine, the point I was trying to make is that an ISP should clearly wear two different hats when assigning:
1. PA addresses from its own allocation
2. PI geographical addresses.
Michel.
-
- This list (global-v6) is handled by majordomo@lists.apnic.net
