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 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
