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