Hi Jari, Yes, the home gateway is the CPE. We will clean up the draft use only one term to eliminate any confusion.
For the DNS recommendation. This is needed not only for optimization. The B4 element only receives the v6 address of the DNS servers in dhcpv6 message, it doesn¹t have IPv4 address of any dns server. If the B4 element doesn¹t advertise itself (e.g. 192.168.1.1) as a dns server in the dhcp message to its managed hosts, a v4-only host will not learn any dns server in dhcp. Yes, the host could be potentially set the dns server manually, but this may cause many inconvenience to the ipv4-only host. Do you have any suggestion to pass the v4 address to the B4 element so that the B4 element can pass it to the host in dhcp message? Thanks, Yiu On 8/9/10 11:35 AM, "Jari Arkko" <[email protected]> wrote: > I am reviewing this draft. Please find the first batch of my comments below: > > Technical: > >> >> The common thinking for more than 10 years has been that the >> transition to IPv6 will be based on the dual stack model and that >> most things would be converted this way before we ran out of IPv4. >> >> However, this has not happened. The IANA free pool of IPv4 addresses >> will be depleted soon, well before any significant IPv6 deployment >> will have occurred. >> >> This document revisits the dual-stack model and introduces the dual- >> stack lite technology aimed at better aligning the costs and benefits >> of deploying IPv6. Dual-stack lite will provide the necessary bridge >> between the two protocols, offering an evolution path of the Internet >> post IANA IPv4 depletion. >> > > I would partially rewrite this. The claims are strong, but at least from my > point of view, while dual stack lite solves specific problems it is not a > general replacement for dual stack. Here's my suggested new text: > > The common thinking for more than 10 years has been that the > transition to IPv6 will be based solely on the dual stack model and that > most things would be converted this way before we ran out of IPv4. > However, this has not happened. The IANA free pool of IPv4 addresses > will be depleted soon, well before sufficient IPv6 deployment will > exist. As a result, many IPv4 services have to continue to be provided > even under severely limited address space. > > This document specifies the dual-stack lite technology which is aimed at > better aligning the costs and benefits in service provider networks. > Dual-stack lite will enable both continued support for IPv4 services > and incentives for the deployment of IPv6. It also de-couples IPv6 > deployment in the service provider network from the rest of the Internet, > making incremental deployment easier. > > At the same I would also rewrite parts of the abstract: > > OLD: > This document revisits the dual-stack model and introduces the dual- > stack lite technology aimed at better aligning the costs and benefits > of deploying IPv6. > NEW: > This document revisits the dual-stack model and introduces the dual- > stack lite technology aimed at better aligning the costs and benefits > of deploying IPv6 in service provider networks. > >> >> A DS-Lite home gateway SHOULD NOT operate a NAT function on a B4 >> interface, as the NAT function will be performed by the AFTR in the >> service provider's network. > > I am not sure what it means to operate a NAT function on an interface. > Presumably it would be operated between two interfaces. Perhaps you wanted to > say that "the GW SHOULD NOT operate a NAT function". > >> >> It SHOULD also advertise itself as a DNS server in the DHCP >> Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy >> to accept DNS IPv4 requests from home hosts and send them using IPv6 >> to the service provider DNS servers, as described in Section 5.5 >> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-05#section-5. >> 5> . >> > > It is unclear to me why you need to make these recommendations (but I'm > reading on). This material in general seems more suited to a homegateway RFC > than DS-Lite RFC. Also, I do not understand why the usual passing of service > provider DNS server addresses is unsuitable in this configuration. I see the > comment later that says a large number of DNS requests might create a lot of > unnecessary state. But there seems to be complexity that the text glosses > over. Operating a real DNS server might be more than what simple gateways want > to implement or configure. Its not clear that proxied requests from the > gateway are in any way less taxing for the NAT (at least my Linux box uses a > different source port on every request, so I might as well have all hosts send > their own requests). And I'm not sure if you wanted to say "in addition" or > "alternatively" for the DNS proxy. > >> 3. Terminology > > I am pretty sure there should be other terms as well, starting from dual stack > (RFC 4213), NAT, CPE/home gateway, etc. > > Editorial: > >> >> == Outdated reference: A later version (-04) exists of >> draft-cheshire-nat-pmp-03 >> >> == Outdated reference: A later version (-02) exists of >> draft-droms-softwires-snat-01 >> >> == Outdated reference: A later version (-01) exists of >> draft-durand-dual-stack-lite-00 >> >> == Outdated reference: A later version (-05) exists of >> draft-nishitani-cgn-04 >> >> == Outdated reference: draft-templin-seal has been published as RFC 5320 >> > Idnits reports that some of the references are outdated. Please correct these. > > Section 1 would benefit from an overview of what the remaining sections will > cover. > > The document talks about home gateways and CPEs. Is there a difference, or > should you be using the same term? > > Jari > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
