[address-policy-wg] IPv6 PI for HOSTING

Le 5 janv. 2010 à 14:00, Masataka Ohta a écrit :

> Remi Despres wrote:
> 
>> Note, besides, that the work I started on SAM (stateless map-and-encaps
> 
> FYI, the architecturally correct solution, which is applicable both
> to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt
> issued on April 2000.

Thanks for the interesting reference.

However, talking about THE solution seems to me too much: 
- The SAM approach (to be soon renamed Mesh-softwire lite - MSL) avoids your requirement that hosts run BGP, and support the full worldwide routing table. 
- Named based extensions of socket APIs seem IMHO to have more potential than multiple address APIs.

>> (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01
>> are planned to be replaced by a better successor for IETF77).
> 
> FYI, selection of the proper address requires the concept of
> time out, which does not exist in connectionless IP layer, which
> means the problem must be solved in transport layer (TCP) or
> above (applications over UDP).

It is clear that UDP is adequate only if E2E paths are not too frequently broken, and if broken connections are acceptable if they are rare.

To change connection addresses on the fly, if needed to avoid breaking connection when E2E paths break, using DCCP in place of UDP seems a natural approach (and using SCTP, Shim6, or Multipath TCP, in place of TCP). 

     
> NAT-like approaches to solve the problem at the IP layer are
> all broken.

Agreed.
But note that the SAM-MSL approach is not in this category.  


>> I agree that IPv6 address allocation policies still need evolution.
> 
> With 4B or 6B port numbers, the problem can be solved as address/port
> allocation polices of port restricted IPv4.

Such a drastic evolution, only justified to avoid IPv6, would be unreasonable.
(IPv6 is available in router and host products, and successfully deployed in some subsets of the Internet.)


>>> Another example is a problem of transport payload size. Please
>>> simply answer the following question:
>>> 
>>> 	With 1280B of path MTU, how many bytes, do you think, are
>>> 	assured to be carried over UDP over IPv6 without
>>> 	fragmentation?
> 
>> Since fragmentation is in IPv6 an end-to-end function, I don't
>> see why it would be important to have a fixed value for this number.
> 
> There is a reason why ISPs must filter ICMPs against fragmentation
> errors. What, do you think, will happen if your access and backbone
> MTU are 1500B and you send 1500B multicast packets to people many
> of which are using PPPoE? If ISPs filter ICMPs against multicast
> fragmentation errors, most ISPs will filter all the ICMPs.

In IPv6, fragmentation errors being an end-to-end matter, ISPs that don't support IPv6 multicast themselves are not concerned.
E2E fragmentation is IMHO one of the significant pluses of IPv6.

> Worse, even if fragmentation had worked, there can be indefinitely
> lengthy optional headers *BEFORE* a fragmentation header that you
> can not even assume fragmentation possible.
> 
>> (A sender that needs no IPv6 option may send without fragmentation
>> more payload bytes than another that needs some options, e.g. for
>> IPsec. Why would this be a problem?)
> 
> Because, optional header is not always under the control of
> applications, as exemplified by MIPv6 headers.

Applications are and must remain unaware of whether their datagrams are transmitted in single or multiple fragments.


>> Having formats that don't limit lengths is good to have, but
>> doesn't imply that there exists no practical limit.
> 
> FYI, my proposal to IPv6 WG to limit the length to allow for
> 512B or 1024B DNS message size was voted down, which means the
> practical limit, conceived by IPv6 WG, can be as large as or
> even larger than 1280B.
`
The IP layer introduces per se no constraint on DNS-message lengths. 
This is not an IP layer issue. 


>> In practice today, the fragmentation option having to be in
>> the first packet (limited to 1280B if nothing better is
>> guaranteed), and the length of options that follow being
>> limited even for sophisticated uses (IPsec or mobility),
>> there is AFAIK such a practical limit today.
> 
> Please simply answer the following question:
> 
> 	With 1280B of path MTU, how many bytes, do you think, are
> 	assured to be carried over UDP over IPv6 without
> 	fragmentation?
> 
> If you can't, you may assume some practical upper limit on IPv6
> optional header length and standardize it in IETF. Then, you can
> start deploying modified specification expecting that
> implementations of it will be widely deployed within the next
> 20 years.

Native IPv6 is deployed today and, for its users, works fine for a number of applications (without harm to other applications that use IPv4 as before).
I don't understand this point about needing to wait.


> 
>>> Note also
>>> that DNS (plain ones without DNSSEC) requires 512B must be carried
>>> over UDP.
> 
>> No problem in IPv6, even if, due to a non typical number of
>> options, datagrams would need to be fragmented.
> 
> With IPv4, header length of which is at most 60B long, fragmentation
> is always possible. With IPv6, you can expect nothing.

I don't understand what you mean.
 
> 
>> End to end NAT is in my understanding a proposal that eliminates
>> these limitations if added to the current IPv4.
> 
> No, it's not an addition. It's a way to implement NAT, which requires
> no changes on IPv4 routers in public or private IP networks.

To me, extending the specification of IPv4 NATs and of IPv4-capable hosts is a modification of the IPv4 protocol suite.
But this is just a vocabulary question.
The important fact is that existing products generally support IPv6 basic functions, and generally AFAIK don't support E2E-NAT. 

>> This works already where providers, like Free in France, offer
>> native IPv6 in addition to NATed IPv4.
> 
> It's a lot of fun to see ISPs, not knowing how ICMPv6 works against
> multicast fragmentation errors, say they deploy IPv6.

It's not that they "say" to have deployed it: their customers, of which I am, actually use it. 
The fact that they don't support multicast can be reason why their IPv6 service works nicely.
(But note that they don't support multicast in IPv4 either.) 

I am not familiar enough with this issue to discuss it more.
A good reference about it would be appreciated.  

>> IMHO, it would be useful at this stage to list IPv6 functions
>> that can be used safely and usefully.
> 
> Thanks to indefinitely lengthy optional headers, no applications
> work safely over IPv6.

This statement seems to me completely ideological!
There exists today, and in the real world, applications that DO WORK safely over IPv6.
Are you ignoring it? Or willing to deny it?

If a host has a native IPv6 address, its real world OS (Windows, OS X, Linux etc) does not add options that might create problems.
(AFAIK, the only option used is for fragmentation.)

It's time, IMHO, to avoid fighting the lost battle against IPv6 being deployed and used.


RD