Hi, Yiu.

I fid this draft useful. 
More comments below.

Le 27 oct. 2010 à 09:21, Lee, Yiu a écrit :

>> ...               
>>>   tunnel points are responsible to handle the fragmentation.  In
>>>   general, the Tunnel-Entry Point and Tunnel-Exist Point should
>>>   fragment and reassemble the oversize datagram.
>> 
>> I understand that, if DF is not set, the tunnel entry point (or more
>> accurately, the IPv4 entity forwarding the packet into the tunnel
>> entry point) should fragment the packet. But unless you are re-inventing
>> SEAL, the tunnel exit point will just forward the fragments, won't it?
> 
> [YL] Ok. I think we need to rewrite it to make it clear. All we are saying
> is the IPv4 host behind B4 doesn't know the IPv4-in-IPv6 tunnel. So it is
> possible that the host sends a 1500-byte packet. When B4 receives the
> packet, the packet will be over-size with the tunnel overhead. In this
> case, B4 must encapsulate the IPv4 into an IPv6 package first, then
> perform IPv6 fragmentation. B4 must not fragment the IPv4 packet before
> the encapsulation.

The following alternative should IMHO be at least permitted:
The IPv4 packet with DF not set is split into fragments small enough for each 
one to fit, with its encapsulation header, in the tunnel MTU.
Thus:
- Reassembly of IPv6 isn't needed at tunnel exit (simpler and causing less 
delays)
- the overhead of the IPv6 extension header that is needed for fragmentation is 
avoided.


>> ...
>>>   Although only a few studies of per-user port usage
>>>   have been done, an AFTR should be able to support 3000 - 5000 users
>>>   per public IPv4 address.
>> 
>> I find this number astonishing. We know that 200 open ports per user has
>> been reported as typical in some ISP secnarios; that suggests that even as
>> many as 300 users per public adress is close to the limit.

>> 
> [YL] When we said 3000 - 5000 users, we mean *all* users including active
> and inactive users. We will rewrite this to make this clear.

The maximum number of ports that customers will be authorized to use, both on 
the average and individually, should IMHO remain free from any recommended 
numbers.
Each provider will have to make its decision based on many parameters of its 
own.
In particular, as IPv6 takes momentum, less and less IPv4 ports per customer 
will be needed over time.

A proposal would be to delete the sentence as being out of scope. 
(No one who may have problems with a choice in the 3000-5000 range should be 
able to say that IETF is responsible, because of the "should".) 

Regards,
RD




_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to