Subject: [dhcwg] dhcpv6 'zone suffix' option

From: Mark Stapp <[email-masked]>
Date: Tue, 09 Nov 2004 10:34:17 -0500

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?

-- Mark

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 11:26:22 -0500

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.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 9 Nov 2004 18:07:35 -0500

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, November 09, 2004 11:26 AM
> To: Mark Stapp
> Cc: [email-masked]
> Subject: Re: [dhcwg] dhcpv6 'zone suffix' option
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2004 09:34:00 -0500

If we're going to use a flag bit, then it's better to just have a 
different option that means "this is your zone."   It's silly to 
overload it with a bit.   The format for the options can be identical, 
if it makes sense, but there's no reason to complicate the option with 
control bits.   I see your point about putting the option in the IA, 
Bernie - that makes sense.   I think that's what we talked about 
before, although I admit I hadn't mentally made the distinction.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 10 Nov 2004 10:13:07 -0500

I agree that using a separate option is the best (and we might as well let
the author of that separate draft continue that work). This also benefits
the case for putting the FQDN in the IA_* options area.

About the location of the FQDN option, yeah ... I keep forgetting the
complexities involved, since we have to handle client to server and server
to client communication and if the option is allowed to appear in multiple
places, it gets very messy.

For example, if the option were just in the IAADDR options area, many client
to server messages don't include any IAADDRs. So, this would force the
option to also be allowed in other places (IA_* options or message options).
This greatly complicates the client and server processing code.

By putting it in the IA_* options, we're restricting it to stateful (PD or
NA) but I don't think that's an issue (especially if we don't use it to
communicate the zone name).

For Information-Request, the separate option can be used to communicate the
zone. There's no reason to use the FQDN option for this as the server can't
do any updates for the client since it has no idea what the client's
addresses are.

So, this means that there is NO immediate reason for me to revise
draft-ietf-dhc-dhcpv6-fqdn-00.txt. Therefore, PLEASE REVIEW THIS DRAFT and
provide me comments -- good and bad -- so we can determine whether to revise
it or start the WG Last-Call.

- Bernie

> Sent: Wednesday, November 10, 2004 9:34 AM
> To: Bernie Volz
> Cc: [email-masked]; 'Mark Stapp'

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 11 Nov 2004 01:17:10 +0900 (JST)

Source Address Selection Policy option for DHCPv6
   <draft-hirotaka-dhc-source-address-selection-opt>

We got some comments and questions at the meeting. (thanks a lot!)

One big question was why we use DHCP where dynamic changes could be
occurred.

Our proposal in this draft is to distribute the source address
selection policy mainly at the node set up stage, and not changing the
policy dynamically.  And as Ted kindly pointed out in the meeting, we
assume the policy is static and the lifetime of the distributed policy
is bound to the address assigned to the node.

When one upstream link goes down, dynamic changes to the user network
will occur. The changes could be revoking address prefix assigned from
the failed link, and at that case, the policy bound to that assigned
prefix would be also revoked. This change is caused by the revocation
of that address prefix, and not caused by other trigger.

So, we do not assume the dynamic changes such as routing affect to the
policy directly.

I hope this could be an answer to the question John asked.

Yours sincerely,
--
Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2004 13:20:32 -0500

> communicate the zone name).

I would encourage you not to put any language in the draft that 
explicitly refers to stateful versus not stateful.   I think it's 
likely that we will want to support dynamic DNS updates with the 
Information Request message using the FQDN option.   In this case, the 
client would have to send an IA option, in order to identify it for the 
purposes of doing the DNS update.   So if you don't explicitly say 
anything about stateful vs. non-stateful, we don't need to update your 
draft when we write a draft explaining how to do updates with stateless 
DHCPv6.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 10 Nov 2004 13:40:21 -0500

Fine by me. I'll double check but I don't believe that I mentioned stateful
in the current draft.

> Sent: Wednesday, November 10, 2004 1:21 PM
> To: <[email-masked]> <[email-masked]>