Replying to selected comments in line...
- Ralph
At 06:58 PM 6/25/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>>>>> On Wed, 23 Jun 2004 08:33:56 -0400, >>>>> Ralph Droms <[EMAIL PROTECTED]> said:
>> 5. Section 3.1 >> >> The configuration of DNS server address can be >> performed manually by operator or automatically DHCPv6 client >> running on the router. >> >> We need some clarification here to apply "dynamic *HOST* configuration >> protocol" to the *router*. Yes, we did a similar usage for prefix >> delegation (RFC3633) where a requesting *router* acts as a DHCPv6 >> client. In my understanding, however, that was a very special case >> which can be considered as an exception. Even if we agree on using >> the same logic again, I still believe this document should clarify the >> point explicitly.
> Interesting point. In my mind, there is some room for interpretation > of the interfaces on a router acting as "host" or "router" interfaces. > I think there was some discussion about the differentiation between > interface function as "advertising" or "non-advertising"? > In the PD case, the use case is a CPE router, with one interface connected > to the ISP network that acts as a "host" interface and one or more > interfaces to the customer network acting as "router" interfaces. In this > use case, it seems reasonable to allow DHCPv6 on the CPE interface to the > ISP.
It's probably reasonable for the PD case, but the description in this section seems to talk about more generic cases. I'd personally rather make this part less specific as Bob suggested (to my first comments).
Agreed - no particular reason to mention DHCPv6 here...
>> 15. Section 4 (Interworking among IPv6 DNS Configuration Approaches) >> >> For ordering between RA and DHCP approaches, O (Other stateful >> configuration) flag in RA message can be used [5]. If no RDNSS >> option is included and O flag is set on in RA message, an IPv6 Host >> may perform DNS configuration through DHCPv6 [6]-[8]. >> >> Note that we are going to loosen the relationship between the O flag >> and the invocation of DHCPv6 in rfc2462bis. Right now, I'm not sure >> how we can reflect the forthcoming change in this document though (or >> whether we need to reflect that in the first place).
> In particular, the new text in rfc2462bis does not preclude the use > of stateless DHCPv6 when the O flag is not set. Thus, a host that > requires the address of an RDNSS might well try stateless (or even > stateful) DHCPv6 if it doesn't receive an RA with an RDNSS option.
...even if the RA does not have the O flag being set, right? So you might say:
For ordering between RA and DHCP approaches, O (Other stateful configuration) flag in RA message can be used [5]. If no RDNSS option is included, an IPv6 Host may perform DNS configuration through DHCPv6 [6]-[8] regardless of whether the O flag is set or not.
That text is fine with me.
>> 21. In Section 5.1.1 (RA Option Scenario) >> >> For easy configuration on the ISP, >> DNS information, unsolicited RA message including a new DNS option >> can be delegated to its subnet periodically. >> >> I can't parse this sentence. In particular, I don't understand the >> role of the phrase "DNS information" in this sentence.
> Re-reading this sentence for intent, I think it should be qualified > to the case in which all of the CPEs use the same RDNSS. In the > case where different customers use different RDNSSes - for example, > in the MSO/ISP - simple broadcast of an RDNSS option in an RDNSS > won't be sufficient.
> Also, it might be good to be more specific in the case where the > CPE is a customer router "gateway", as the expectation would be > that the CPE accepts the RDNSS information from the RA on the > interface connected to the ISP, and copies that information into > the RAs broadcast in the customer network.
Do you mean the original intention is to provide the RDNSS address in an RA from PE router to CPE router? If so, I could not understand the intention from the original text. More seriously, this approach will lead to an open issue on how a router configures itself by receiving RAs from another router (RFC2461 or 2462 were not clear on this. And we've decided to make this still open at least in rfc2462bis). Of course, we could discuss such an advanced topic here, but I guess it's too early to explore such radical path in this context.
The original intent of the text was not clear to me, either. I may have read more into the text by mentioning the use of the RA option for configuration of CPE routers. But, if all this paragraph describes is the use of the RA option for hosts directly connected to the ISP network, I don't understand why that case is specifically called out in this scenario.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
