Hi Behcet, Please see in line. Le 2012-03-12 à 23:09, Behcet Sarikaya a écrit :
> 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" Editorial improvements can be done later, but thanks for your suggestions. As regards "customer", this word seems to me good enough in an abstract (BTW, the word on which are based CPE and CE acronyms). > Technical: > > I don't understand NAT64+ discussion in this draft (it has been added > in -04). Why do you need it? It came as a result of the discussion on 464XLAT in v6ops (=> copy sent to Cameron Byrne). What is achieved by 464XLAT is AFAIK that, in dual-stack-capable nodes (DS nodes), IPv4-only applications can reach IPv4-only servers via NAT64s. If a DS node is 4rd-capable, and is in a Domain where it has no public IPv4 address (even shared) but where there is a 4rd-capable NAT64 (called a NAT64+), it does all what it does with 464XLAT, but with an improved IPv4 transparency (DF, ICMPv4, DCCP, UDP Lite ...). > In NAT64, IPv6 packet is not created by CE but by the host with the > help of DNS64. So far, the NAT64 doesn't know how packets are created. A NAT64+ recognizes IPv6 packets that were created to tunnel IPv4 packets, and takes, for them, advantage of better IPv4 transparency. > Where is DNS64 in your draft, except for a reference to > RFC 6147 which is a bogus reference. Right, this reference isn't needed. Thanks. (NAT64s always go with DNS4s in the IPv4/IPv6 framework of RFC6144, but this isn't a 4rd matter.) > NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over > an IPv6 network. Indeed, but it also helps DS hosts attached to IPv6-only networks to reach IPv4-only servers, e.g. with BIH. > So it has almost nothing to do with 4rd. Nothing to do with 4rd... until 4rd includes a way to improve IPv4 transparency of NAT64s for hosts that are DS (upgrading them to NAT64+). > > 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. Not in 4rd BRs as defined, only in nodes that colocate BRs and NAT64s. > Is this what you would like to do? > > Maybe I missed something. Hope the above is clarifying. Kind regards, RD > > 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
