[dhcwg] 答?: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt

["CTO YAN Renxiang" <[e-mail]>]

> -----原始?件-----
> ?件人: JINMEI Tatuya / ノ？？_ヤユ [mailto:[e-mail]]
> ?送??: 2005年3月10日 12:30
> 收件人: CTO YAN Renxiang
> 抄送: [e-mail]; CTO Jiang YingLan
> 主?: Re: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt
> 
> 
> >>>>> On Thu, 10 Mar 2005 09:46:45 +0800, 
> >>>>> "CTO YAN Renxiang" <[e-mail]> said:
> 
> >> My first question is whether it's typical for the 
> "subscriber" to use
> >> the ISP's (sub) domain (suffix) for its internal host names.  This
> >> would make it hard to change providers (they'd rename host names as
> >> well as renumber addresses), so don't they rather want to use an
> >> independent domain space?  Perhaps I'm just unfamiliar 
> with this area,
> >> so this is not an objection to the proposal; rather it's just a
> >> question.
> 
> > This option just provides a method to transfer the domain 
> suffix from DHCPv6 server
> > to DHCPv6 client. The word "provider" is used as an example 
> to illustrate the 
> > applicability, you certainly can use an independent domain 
> space, but typically, to reduce
> > management cost, the allocation of this indenpendent domain 
> space is performed 
> > by the network service provider. 
> 
> Thanks for the explanation, but this does not really address my
> concern.  What I wanted to see is an explanation on how this is
> realistic in the actual operational usage, rather than "this could
> work in theory this way".  As you seemed to indicate, providing an
> independent name space from the upstream ISP does not seem feasible to
> me.

I think explaining a typical usage can help to understand the option. I will explain
other issues after the purpose of the option make sense to you.

Suppose a CPE in IPv6 access network. The CPE is linked with many IPv6 terminals
in home network. The CPE get an IPv6 prefix from uplink access node (e.g. BRAS)
through Prefix delegation. The address of the terminals in home network can be 
configured using stateless autoconfiguration or through a stateful DHCPv6 embedded in
CPE. Now, my concern is how to automatic update a domain name for the IPv6 terminals?

1. In the case where terminals address is configured using DHCP. we can use FQDN 
option between terminals and CPE. So we need to configure a zone suffix in the DHCPv6
server embedded in CPE. However, for a large number of CPE, it's better to define an
automatic way. So we define this option.
2. The typical case is terminals' address is configured using stateless autoconfiguration. 
There has been several drafts address how to update domain name in such environment,
but a zone suffix still needs to be configured in the CPE.

So this draft defines the option to transfer zone suffix using DHCPv6, but it does not 
address the DNS update for the terminals.

> 
> >> I also understand most of Section 2.1:
> 
> (Oops, sorry, I actually meant "I also don't understand" here, BTW)
> 
> >> Also, I cannot be sure how an end host using stateless address
> >> autoconfiguration can update its host name using this 
> mechanism (e.g.,
> >> how can the node know the appropriate "suffix"?).  I hope 
> this draft
> >> will provide a bit more details on this.
> 
> > This document does not address this issue, the host's 
> address can be configured
> > using DHCPv6 or stateless autoconfiguration. The FQDN 
> option provide a method 
> > to update domain name for the host configured using DHCPv6. 
> The domain name 
> > update mechnism for the node whose address is configured 
> using stateless 
> > autoconfiguration remains an ongoing issue, you can refer 
> to another draft in:
> > http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt
> 
> ??? I'm now totally confused...According to this explanation,
> 
> - for a host using DHCPv6 for address configuration, we use the FQDN
>   option.
> - a host using stateless address autoconfiguration is not in the scope
>   of the zone suffix option.
> 
> then why do we need the new option in the first place?
> 
> Please be more specific on the expected usage.
> 
> >> In stateful DHCPv6, the zone suffix option MUST only appear in 
> >> IA_PD-options field of IA_PD option (see [3]) and apply to all 
> >> prefixes for that binding.  One IA_PD-options field MUST 
> >> include none
> >> or only one zone suffix option.
> >> 
> >> What does "stateful DHCPv6" mean in this context?  Does 
> this specify
> >> address allocation (at end nodes) by DHCPv6?  Or does this 
> mean prefix
> >> delegation?
> 
> > It means "prefix delegation" using DHCPv6. Such kind of 
> usage has been discussed
> > in the DHC mailing list before.
> 
> > The term "Stateful DHCPv6" is compared with "stateless 
> DHCPv6", they are 
> > specified respectively in RFC3315 and RFC3736.
> 
> Of course I know those wording and RFCs.  But in my understanding,
> stateful / stateless are typically used in the context of address
> configuration.  In the context of prefix delegation, there's no
> "stateless" counterpart.  That's why I was confused.
> 
> But I'm afraid it doesn't make sense to continue disucssing the
> wording issue unless the expected usage is clarified (see above).
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[e-mail]
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg