, Yiu wrote about draft-lee-softwire-6rd-udp-01: > 1. How to discover 6rd parameters? ISP relies on radius can pass the > parameters over the existing infrastructure. However, ISP relies on dhcp > may require some OOB discovery procedure.
See my draft: http://www.ietf.org/id/draft-baldwin-dhc-softwire-anycast-dhcp-00.txt > > 2. Since the 6rd udp host is behind NAT, so it won't know the NAT-ed udp > port after NAT-ing. We solve this problem by asking the 6rd BR to fill in > the port information. However, this design virtually creates a NAT66 > scenario. The BR should inform the host what port number is being used. A potential problem is that it uses a lot of address space, a /48 per IPv4 address. It also lacks the direct peer to peer communication that is possible using 6RD, 6to4 and Teredo. Would the server model be popular enough to justify the use of large amounts of address space? Could not DHCPv6 be used to allocate address to the hosts? Two alternative approaches, use a well known destination port combined port- forwarding configured using UPnP, NAT-PMP or manually. This has the same address efficiency as classical 6RD. Or use a /64 prefix like Teredo, using 48 bits for the IPv4 address and port, leaving 14 bits to address local hosts, but I expect such use to be uncommon. There would need to be a protocol to find a shorter route perhaps transversing NATs, behind the same NAT, or perhaps native on the same link. The border router remains stateless. > Our goal for this technology is promoting IPv6 even in the situation where > the ISP doesn't manage the home gateway. This is a low cost add-on to the > class 6rd and help the ISP to transition to IPv6 in a faster pace. Potentially too fast, if a large portion of ISPs deploy it then the client is deployed by an automatic update. There would need be some rules to make the deployment gradual. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
