Re: [v4tov6transition] comments on draft-despres-softwire-6a44-00

[Rémi Després <[e-mail]>]

Thanks Washam for your detailed comments.

Personal reaction below.

Le 7 oct. 2010 à 13:46, Washam Fan a écrit :

> Hi,
> 
> Thanks for your work on this issue.
> 
> I have some comments:
> 
> 1. From 6a44 address format, the 6a44 client can only act as a IPv6
> host but not IPv6 node which could attach to a IPv6 LAN. I think this
> is different from draft-lee-softwire-6rd-udp.

Yes.
But 6rd-udp had such limitations on prefix lengths that it would have had to be modified.
Private discussions led to only envisaged it, in practice, with a stateful NAT66 in the 6rd-udp client.
If a NAT66 in a customer site is accepted, 6a44 can be used to provide its external address. 

> 2. For host to host 6a44 communication, I think there is assumption
> that only one-layer NAT deployed between 6a44 hosts and 6a44 servers.

Yes.
There must be only a *LAN* between 6a44 hosts and CPEs (Fig. 1)

> 3. There is no text in the draft regarding to 6a44 server address
> provisioning.

Good point.
The information exists, but only indirectly (which is insufficient).
The IANA section says:
"For 6a44 to be used, both its IPv4 well-known address B and its well-known port W need to be assigned by IANA."

We could for example add in a next version a bullet in section 4 to say:
"B is the well-known IPv4 anycast address of the 6a44 Server function."


> Since 6a44 servers are stateless, could anycast
> addresses be used? If there are some methods for this provisioning,
> 6a44 server would no need to use well-known UDP ports.

B is indeed an anycast address, as shown by:
"The 6a44 server function can be replicated in any number of routers, known as "6a44 Relays."

The added bullet above, which better defines B, would make it clearer.

> 4. The draft presents 2 restrictions applying for 6a44 deployment in
> terms of MTU issue:
> 
>   o  6a44 ISP networks must have internal IPv4 MTUs of at least 1308
>      octets (which is easy to ensure).
> 
>      *  6a44 hosts must limit to 1280 octets IPv6 packets they transmit
>         to destinations that are not neighbors on their own links.
>         This behavior is already the normal one as long as no other
>         IPv6 path MTU has been reliably discovered.
> 
>   o  6a44 Server functions refuse packets received from their IPv6
>      pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6
>      Packet Too Big messages returned to sources as required by
>      [RFC2460].)
> 
> I assume the must appearing in the first bullet would have been MUST.

Yes.
It can be clarified in the next version.

> I don't know the second bullet is MUST/SHOULD/MAY or anything else.
> Personally, MUST might be too restrictive for the second bullet.

This point isn't 100% clear, I agree.
The text can be improved.
(Yet, as long as PMTU discovery isn't considered reliable, the suggested course of action is the only one that preserves connectivity, which IMHO is a MUST.)
 
> (My Provider deploys NATs in the residential area I live, for some
> apartments, there might be another NAT, itcould be easy to see 2-layer
> NATs for me;-)

Your provider is in the second case of Figure 1. 
To support 6a44, it MUST therefore have a 6a44 Server function next to its NAT function, at entrance of each residential area. 
If it can't, 6a44 isn't a solution for its network.

No simple solution seems to exist in this case, if the IPv6 traffic between hosts of an apartment remains within the apartment (which is considered a MUST for a deployment without customers having bad surprises).


Regards,
RD

PS: I added the two co-authors as cc destinations.
  
> 
> Thanks,
> washam