JINMEI san;
My comments on your comments on WKA approach.
Perhaps, I should provide revised text on WKA part, if we can
reach a consensus.
> With the approach of well known addresses, the configuration load will
> depend on how much we should do to set up routing for the well known
> addresses. In an extreme (but not so rare) case where no route
> filters are configured within the administrative domain, we basically
> should not have to do anything special in routers.
"within the administrative domain" should be "within or between
the administrative domain".
It should also be noted:
As DNS servers need configuration and the number of separate
administrative domains is proportional to (or less than) the
number of DNS servers, the amount of configuration on routers
scales.
> 12. Section 3.3 (Well-known Anycast Addresses)
>
> I believe this draft should clarify that "anycast" is a different
> notion from the one defined in the IPv6 addressing architecture (e.g.,
> RFC3513). For example, reference [9] of this draft requires using the
> anycast address as a source address for TCP responses while the
> address architecture prohibits this usage.
Yup. The fundamental difference to is that it is assumed to be
administratively prohibited to have anycast servers sharing
an anycast address in a single link. Then, most of instabilities
disappear.
> 13. Section 3.3 (Well-known Anycast Addresses)
>
> Readers would expect the same organization for this section as that
> for Sections 3.1 and 3.2: general description, advantages,
> disadvantages, and observation. It might be helpful for readers if
> Section 3.3 can use the same organization.
OK.
> 14. Section 3.3 (Well-known Anycast Addresses)
>
> Well-known anycast addresses can be combined with cryptographic
> security such as TSIG or DNSSEC. However, there is no point to
> avoid manual configuration of DNS when secret information (such as
> a shared secret key or a public key of root zone) for the
> cryptographic security must manually be configured (and updated
> periodically).
>
> I don't understand the role of this paragraph in the context of this
> section or of the entire document...perhaps additional background
> might help or we can simply remove this paragraph?
The intention is to say that there is no secure ND nor secure DHCP,
unless you manually configure a lot. :-)
With the current security consideration section, the paragraph
can be removed.
> 16. Section 5.2.1 (Multi-level Network Topology)
>
> The rest of routers below can automatically configure
> DNS information through DHCPv6.
>
> The same note on the use of DHCPv6 to routers applies here (see
> comment 5 above).
>
> Additionally,
>
> For redundancy and load sharing, well-known anycast
> addresses can be used by IPv6 hosts through RDNSS RA option.
>
> This statement seems to contradict with Section 3.3 where the draft
> says anycast addresses are not for redundancy.
Huh? 3.3 of the draft says:
Large ISPs may
operate multiple recursive resolvers at each anycast address to
distribute and reduce load
> 17. Normative References
>
> There are two work-in-progress documents:
>
> draft-jeong-dnsop-ipv6-dns-discovery-01.txt
> draft-ohta-preconfigured-dns-01.txt
>
> Can't we have these as normative references unless these are published
> as a stable document (presumably an RFC) before the publication of
> this document or at least synchronously? Or is that actually the
> plan?
ID can refer anything.
Masataka Ohta
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
