Subject: [dhcwg] DHCPv6 Confirm Message

From: Hiroshi MIYATA <[email-masked]>
Date: Wed, 17 Sep 2008 19:14:27 +0900

Hi all,

I found a unexpected(for me) behavior in Confirm/Reply message exchange.

The client sends Confirm Message with IA address=2001:db8:1:1::1000
The server sends Reply Message with IA address=2001:db8:1:1::1001
with the status code=0(success).

In RFC3315,

2768 18.2.2. Receipt of Confirm Messages
2769
2770    When the server receives a Confirm message, the server  
determines
2771    whether the addresses in the Confirm message are appropriate  
for the
2772    link to which the client is attached.  If all of the addresses  
in the
2773    Confirm message pass this test, the server returns a status of
2774    Success.  If any of the addresses do not pass this test, the  
server
2775    returns a status of NotOnLink.  If the server is unable to  
perform

I would like to confirm the meaning of the sentence.
"the addresses in the Confirm message are appropriate for the link"
Does it mean server needs to check the validation of the prefix(64bit)
or entire address(128bit)?

I feel that "if the validation check is done only for the prefix,  
sending
another address with status code=0 sounds reasonable".
But "if the validation check is done for entire address(128bit), sending
another address with status code=0 sounds unreasonable", since the  
address
in Confirm Message is not to be used.

Thanks for your clarification!

Kindly Regards,

.....miyata@tahi
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 Sep 2008 07:51:35 -0700

> or entire address(128bit)?

The validity for the link (64bit or whatever the prefix length is).

In fact, if you read 3315 section 18.2.2 carefully, you will find that
there is no direction to include the client's IA at all.  It is rather
strange that the server you are looking at includes both an IA and an
IAADDR.  By doing so, it is not engaging in RFC3315 specified
behaviour, but I suppose neither is it explicitly forbidden...

My main concern for the server you're looking at would be whether or
not its implementor has extended or created a lease-time association
with the address it has supplied.  That would be the worst I could
imagine for protocol interop, as it begs some client to come to the
same conclusion.

It's important that the Confirm message, which is at present
lightweight as it does not require database updates or even
(non-IP-address-related) configuration knowledge, remains as simple
as currently specified.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 11:12:31 -0700

> behaviour, but I suppose neither is it explicitly forbidden...

The behavior you're seeing is incorrect.   RFC3315, p. 41, says:

    Confirm message.  Any responding servers will indicate whether those
    addresses are appropriate for the link to which the client is
    attached with the status in the Reply message it returns to the
    client.

This is in the description of the client behavior, but we can clearly  
see the intent here.

Again on p. 47, we see this:

    If the Reply was received in response to a Solicit (with a Rapid
    Commit option), Request, Renew or Rebind message, the client updates
    the information it has recorded about IAs from the IA options
    contained in the Reply message:

Again, a reply in response to a confirm is clearly excluded - the  
client is not being directed to take information from IAs it may  
receive in a Confirm message, and is directed to take information from  
those IAs in all other cases.

On p. 48:

    When the client receives a NotOnLink status from the server in
    response to a Confirm message, the client performs DHCP server
    solicitation, as described in section 17, and client-initiated
    configuration as described in section 18.  If the client receives  
any
    Reply messages that do not indicate a NotOnLink status, the client
    can use the addresses in the IA and ignore any messages that  
indicate
    a NotOnLink status.

So clearly the way that we get a new address if we get a NotOnLink  
status back from the server is to go back to solicit, not to take  
whatever is in the IA in the Reply to the Confirm message.

And then on p. 50:

    When the server receives a Confirm message, the server determines
    whether the addresses in the Confirm message are appropriate for the
    link to which the client is attached.  If all of the addresses in  
the
    Confirm message pass this test, the server returns a status of
    Success.  If any of the addresses do not pass this test, the server
    returns a status of NotOnLink.  If the server is unable to perform
    this test (for example, the server does not have information about
    prefixes on the link to which the client is connected), or there  
were
    no addresses in any of the IAs sent by the client, the server MUST
    NOT send a reply to the client.

There is no mention of sending IAs back to the client.

By contrast, on p. 51, when talking about constructing a Reply to a  
Renew, RFC3315 says this:

    If the server finds the addresses in the IA for the client then the
    server sends back the IA to the client with new lifetimes and T1/T2
    times.  The server may choose to change the list of addresses and  
the
    lifetimes of addresses in IAs that are returned to the client.

So the RFC is specifically directing the server to send an IA in this  
case, whereas it says nothing about sending an IA in the case of a  
Confirm.

So the server in question is simply out of spec.   We can expect  
badness to ensue - if the client continues to use the addresses it is  
entitled to use, there is no guarantee that the server will not  
allocate that address to some other client, since it is broken.   And  
of course if the client goes ahead and uses the new address, all its  
connections will be broken.

There is an inconsistency in the RFC in section 18.1.8 - the confirm  
message is included here in the list of messages for which the client  
should parse out configuration information.   I don't believe this is  
correct - the Reply in this case should be a "go" or "no go" in the  
case of a Confirm.

If we do an errata for RFC3315 on this point, we should add text in  
18.2.2 that says "The server MUST NOT include an IA option in its  
reponse," and in 18.1.8 we should add text that says "The client  
SHOULD drop any response from a server that contains IA options."    
And further, we should update the first paragraph of 18.1.8 as follows:

    Upon the receipt of a valid Reply message in response to a Solicit
    (with a Rapid Commit option), Request, Renew, Rebind or
    Information-request message, the client extracts the configuration
    information contained in the Reply.  The client MAY choose to report
    any status code or message from the status code option in the Reply
    message.

    In the case of a Confirm message, the client extracts the result
    code only, and disregards any configuration information included
    in the message.   In the event that IA options appear in the
    message, the client SHOULD discard the message.

Anyway, that's my two cents.   The behavior that Hiroshi Miyata is  
describing cannot be permitted, because there is no safe action for  
the client to take when it gets a response like the one being described.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 Sep 2008 13:17:50 -0700

> The behavior you're seeing is incorrect.   RFC3315, p. 41, says:

I think you mean the behaviour Hiroshi is seeing, and that we are
both in agreement.  I think you've issued a superset of my brief
opinion.

> correct - the Reply in this case should be a "go" or "no go" in the  

That may be something we should issue an errata on.  I will have to
look.  I would hope the wording of this would be in the spirit that
a client should at this point use its previously acquired
configuration.  A good reminder since a client might overlook this
and only use the old addresses.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 13:20:09 -0700

> and only use the old addresses.

True.

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 18 Sep 2008 09:21:29 +0900

Thanks Ted and David!

I agree on your thought.
Actually, I also concerned the description on 18.1.8.
which has explicitly listed Confirm message.

Ted's description clarified this point, too. Great!

I am really clear now. ;-)

With regarding to the last sentence of Ted's proposal,

>    message, the client SHOULD discard the message.

I feel, according to Ted's story, "the client SHOULD discard the  
message."
should be "the client MUST discard the message."
Since Ted clearly mentioned the impossibility of IAADDR in Confirm  
message.
How do you think?

Best Regards,

....miyata

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 18:41:38 -0700

> Since Ted clearly mentioned the impossibility of IAADDR in Confirm

The reason I said "SHOULD" instead of "MUST" there is that clients  
sometimes have to work around broken servers.   If we say "SHOULD" we  
are explicitly forbidding them from doing so, which I think goes too  
far.

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 18 Sep 2008 11:27:28 +0900

I got it!

Thanks,

.....miyata

On 2008/09/18, at 10:41, Ted Lemon wrote:

> sometimes have to work around broken servers.   If we say "SHOULD"  
> we are explicitly forbidding them from doing so, which I think goes  
> too far.
>

---

From: Hiroshi MIYATA <[email-masked]>
Date: Fri, 19 Sep 2008 09:30:55 +0900

I wish Ted's description to be uploaded to Errata, to remove the  
ambiguity
and avoid further problematic implementation!

Thanks,

....miyata

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2008 17:50:07 -0700

> and avoid further problematic implementation!

Ralph, Jim?   Let me know if you want the text in a different form.    
Always assuming there's consensus for this, of course.