I have a couple of comments on the revised doc at http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf -dnsop-ipv6-dns-configuration-02.txt
1. Section 5.1 describes (implicitly) an ISP scenario in which the CPE is a router and there is a customer network behind the CPE. However, section 5.1.1 describes a scenario in which the CPE is a host that is directly connected to the ISP network. I found the jump between scenarios a little confusing wihtout more warning that two scenarios were being described. I also was confused by the last paragraph in 5.1.1, which (I think) applies to the CPE/host scenario and not the CPE/router scenario. If others also find the existing text less than clear, perhaps the following text would improve the clarity:
5.1 ISP Network
A characteristic of ISP network is that multiple Customer
Premises Equipment (CPE) devices are connected to IPv6 PE
(Provider Edge) routers and each PE connects multiple CPE devices
to the backbone network infrastructure [11]. The CPEs may be
hosts or routers. In the case where the CPE is a router, there is a customer
network that is connected to the ISP backbone through the CPE.
Typically, each customer network gets a different IPv6 prefix
from an IPv6 PE router, but the same RDNSS configuration will be
distributed. This section discusses how the different approaches to
distributing DNS information are compared in an ISP network.5.1.1 RA Option Approach
When the CPE is a host, the RA option for RDNSS can be used to
allow the CPE to get RDNSS information as well as /64 prefix
information for SLAC at the same time when the host is attached
to a new subnet [8]. Because an IPv6 host must receive at least
one RA message for stateless address autoconfiguration and router
configuration, the host could receive RDNSS configuration
information in that RA without the overhead of an additional
message exchange. When the CPE is a router, the CPE may accept the RDNSS
information from the RA on the interface connected to the ISP,
and copy that information into the RAs advertised in the customer
network. This approach is more valuable in the mobile host scenario, in
which the host must receive at least an RA message for detecting
a new network, than in other scenarios generally although
administrator should configure RDNSS information on the routers.
Secure ND [12] can provide extended security when using RA
message.2. I doubt the configuration mechanism described in section 5.2.1 would be used in practice and I think we should omit section 5.2.1.
3. Regarding section 5.3.1:
At 11:35 AM 7/7/2004 +0300, Pekka Savola wrote:
RA approach is light-weight especially in wireless environment where RA message is used for IPv6 address autoconfiguration, such as cellular networks.
==> I recall Hesham Soliman saying on IPv6 WG list that the /64 is assigned on a cellular node with the v6 PDP context activation? That is, he argued that there's no need for proxy-ND on the cellular node, as the /64 is assigned independently. The only way to interpret AFAICS is that ND is not used for SLAAC on those hosts, or we were talking of different things.
What is the current state of the use of ND/RA and SLAC in 3GPP in 3GPP, and are there any planned extensions to use ND/RA and SLAC in the future? If ND/RA and SLAC are not currently used, some of the stated advantages of the RA option approach should be reconsidered. That is, if the use of the RA option requires implementation and deployment of ND/RA where it is not specified now in 3GPP, deployment of the RA option would seem to require roughly the same amount of specification, implementation, deployment and traffic overhead as the DHCPv6 option.
4. I don't think Jinmei-san's issues 6 and 13 from http://www.uoregon.edu/~llynch/dnsop/msg02915.html were addressed.
- Ralph
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
