Subject: [Softwires] comments on draft-despres-softwire-6a44-00

From: Washam Fan <[email-masked]>
Date: Thu, 7 Oct 2010 19:46:59 +0800

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.

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

3. There is no text in the draft regarding to 6a44 server address
provisioning. 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.

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.
I don't know the second bullet is MUST/SHOULD/MAY or anything else.
Personally, MUST might be too restrictive for the second bullet.

(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;-)

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Oct 2010 15:12:04 +0200

Thanks Washam for your detailed comments.

Personal reaction below.

> 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. 

> 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)

> 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

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.

> I assume the must appearing in the first bullet would have been MUST.

Yes.
It can be clarified in the next version.

> 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.)
 
> apartments, there might be another NAT, itcould be easy to see 2-layer

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.