Hi Ralph, Your suggestion looks very good. I need the help of several people: Juha, Jinmei-san and Ohta-san.
----- Original Message ----- From: "Ralph Droms" <[EMAIL PROTECTED]> > > 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. > o Okay, I agree at the above text. I have reflected this on our new version just now. > 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. > o Okay, I'll omit subsection 5.2.1, which was written by myself, from our draft. > 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. > o About this, Juha seems to be able to suggest his opinion. > 4. I don't think Jinmei-san's issues 6 and 13 from > http://www.uoregon.edu/~llynch/dnsop/msg02915.html were addressed. > o About issue 6 related to RA approach, I took Jinmei's second suggestion. I omitted a word "simple" from the RA text. The modified text is as follows; -------------------------------------------------------------------------------------- 3.1.1 Advantages The RA option for RDNSS has a number of advantages. These include: 1) The RA option is an extension of existing ND/Autoconfig mechanisms [3][4]. No new protocol mechanisms are needed for extending an ND implementation to support this option. -------------------------------------------------------------------------------------- o About issue 13 related to WKA approach, the reorganization of the text can be done by Ohta-san in order to harmonize with other approaches. After I listen to others' text contribution or opinion, I'll reflect them on 02 version and submit it. Thanks for your work in advance. Paul > - Ralph > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
