RE: [dhcwg] dhcpv6 'zone suffix' option

Well, if we restructure the FQDN option to be in the message options area,
it would confuse the issue when PD (IA_PD) and stateful (IA_NA) are in the
same client request, which at least in some cases this is what I would
expect to happen.

I personally believe the best place for the FQDN option is in the IA_*
options area. If we just have it in the message options area, it isn't clear
as to which addresses (or prefixes) it applies to. If we allow it in the
IAADDR options area, it greatly increases the complexity with likely (at
least for now) marginal gain. While we could allow it in multiple places, at
least initially it is simpler to have it in one place (IA_* options, IMHO).
So, I'm presently inclined to leave the draft alone, at least in this
respect.

Having some means, a flag bit, to clearly communicate that the FQDN is just
the zone seems best to me. This could also be used when the client is
allowed to perform updates -- the server can just send back the zone in the
FQDN and set the flag bit. The client then constructs the FQDN to use.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, November 09, 2004 11:26 AM
> To: Mark Stapp
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6 'zone suffix' option
> 
> 
> On Nov 9, 2004, at 10:34 AM, Mark Stapp wrote:
> > it seemed to me that the discussion in the wg meeting 
> revolved around
> > who was going to do a dns update. to me, it seemed that what was 
> > motivating the zone suffix option proposal was simpler (and less 
> > controversial).
> >
> > the v6 fqdn option, as it's specified now, can't really be used to
> > carry a base domain name from the PE router to the CPE router along 
> > with prefix delegation. are there cases where that is desirable - 
> > where the delegating ISP knows the base dns domain in which the 
> > customer's hosts will reside? if so, then I'd prefer that we extend 
> > the fqdn option so that it can be used to carry just a domain name, 
> > and be used in the prefix delegation flavor of the protocol. if we 
> > think it's necessary to make it clear that the fqdn option is being 
> > used this way, perhaps we could allocate a flag bit in the 
> fqdn option 
> > to indicate that?
> 
> I agree with you, but I don't think there's any reason for a 
> flag - you 
> can tell from the context what is going on - if you get an 
> FQDN option 
> in a prefix delegation message, it's telling you what suffix 
> to use for 
> that delegation.
> 
> I guess the big change would be that if you get a client request with 
> no FQDN option, do you send one back with DNS suffix information, or 
> not?   I guess this could be decided by the ORO.
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg