Hi Remi, My quick comments: editorial on abstract: - The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). remove: for this. Better still have a sentence like: 4rd specifies a protocol mechanism to support Pv4 via a service provider's (SP's) IPv6 network without maintaining per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). - To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets.
It is not customers but it is CPE or CEs, right? - 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145) replace "of" with "with" Technical: I don't understand NAT64+ discussion in this draft (it has been added in -04). Why do you need it? In NAT64, IPv6 packet is not created by CE but by the host with the help of DNS64.Where is DNS64 in your draft, except for a reference to RFC 6147 which is a bogus reference. NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over an IPv6 network. So it has almost nothing to do with 4rd. One thing you can do is to say that NAT64 could be colocated with 4rd BR if Pref64 of NAT is chosen to match 4rd prefix. In that case you need to add support for RFC6145 stateful packet translation as well as the NAT state in 4rd BRs. Is this what you would like to do? Maybe I missed something. Regards, Behcet On Mon, Mar 12, 2012 at 9:56 AM, Rémi Després <[email protected]> wrote: > Hello, all, > > An updated version of draft-despres-softwire-4rd-u is now available at > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 > > Differences with -04 include: > - DHCPv6 options are now specified > - various errors and typos are corrected > - some clarifications are added, following received questions and comments > - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and > within CPEs) > - An editor's note has been added, following a WG-ML discussion, about an > additional Mapping-rule parameter that might be needed to assign privileged > ports to to some shared-address CEs. > - Document layout has been adjusted as a result of other modifications. > - the authors list has been completed. > > Questions and comments are most welcome. > > Regards, > RD > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
