Subject: [dhcwg] Regarding DHCPv6

From: Mari Muthu D <[email-masked]>
Date: Fri, 07 Sep 2007 12:47:21 +0530

Dear All,

I have one doubt in the Tahi conformance DHCPv6 Server Test suit

The below mentioned test case indicate weather Message level status code or
IA level status code

Page no: 169;

Test case: 5.69 Respond for when not appropriate for link(return w/status
code= NotOnlink) 

;

;

Judgment is as follows

.......

The Reply must have IA_NA option with status code option NotOnLink. 

But Verification points as 

<>msg-type

       REPLY (7)

.

.

.

.

<>IANA option

<>Status code option

              Value = NotOnLink

Let me know weather status code present is IA level or Message Level.

Thanks and Regards,

Mari Muthu D

Senior Software Engineer,

Huawei Technologies Co., Ltd.

#1489, Level 3, Leela Galleria,

Leela Palace, #23, Airport Road,

Bangalore - 8          

Keep true, never be ashamed of doing right; Decide on what you think is
right and stick to it.

****************************************************************************
****************************************************************************
****************************************************************************
*   This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, butFrom [email-masked] Wed Sep 12 08:32:09 2007
Date: Fri, 07 Sep 2007 12:47:21 +0530
From: Mari Muthu D <[email-masked]>
To: [email-masked]
Cc: 
Subject: [dhcwg] Regarding DHCPv6

This is a multi-part message in MIME format.
Dear All,

I have one doubt in the Tahi conformance DHCPv6 Server Test suit

The below mentioned test case indicate weather Message level status code or
IA level status code

Page no: 169;

Test case: 5.69 Respond for when not appropriate for link(return w/status
code= NotOnlink) 

;

;

Judgment is as follows

.......

The Reply must have IA_NA option with status code option NotOnLink. 

But Verification points as 

<>msg-type

       REPLY (7)

.

.

.

.

<>IANA option

<>Status code option

              Value = NotOnLink

Let me know weather status code present is IA level or Message Level.

Thanks and Regards,

Mari Muthu D

Senior Software Engineer,

Huawei Technologies Co., Ltd.

#1489, Level 3, Leela Galleria,

Leela Palace, #23, Airport Road,

Bangalore - 8          

Keep true, never be ashamed of doing right; Decide on what you think is
right and stick to it.

****************************************************************************
****************************************************************************
****************************************************************************
*   This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
****************************************************************************
****************************************************************************
****************************************************************************
*

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 12 Sep 2007 09:48:01 -0700

> Page no: 169;

I'm not sure of what document?

> Test case: 5.69 Respond for when not appropriate for link(return w/status

Is this for Request, Renew/Rebind or Confirm?

The behaviour specified in rfc3315 is different for each of these
three categories.

In Request's case, my interpretation is that the server must place
the client's IA_NA with no addresses, but with a status code (in
the IA_NA) of NotOnLink.

In Renew/Rebind's case, for a not-on-link condition, the server
replies with the IA_NA, containing the client's NotOnLink addresses,
all with their lifetimes set to zero.  There is no status code (or if
there is, it is 'Success').

In Confirm's case, no IA_NA is included, and the NotOnLink status
is scoped at the message level.

Hopefully this is clearer?  It's not simple.

Following on the client's side implementation in processing replies
made by the above;

In Request's case, I will accept a NotOnLink scoped anywhere (even in
the IAADDR) to send the client back to Solicit.  I will also accept
Renew/Rebind behaviour - any addresses with zero lifetime are removed.
I think both of these are (if implicitly) RFC3315 requirements.

In Renew/Rebind's case, I will again accept a NotOnLink status code
scoped anywhere, and send the client back to Solicit.  In essence,
permitting Request-defined behaviour.  I do not think this is
required in RFC3315.  I think accepting zeroed lifetimes is the only
client requirement (but it's hard to say for certain since all client
requirements for all three of these cases are encapsulated in 17.1.4).
However, I think a client that doesn't respond to NotOnLinks in this
fashion is going to run incompatibility risks, and it's bad guidance
to think there is a choice.

In Confirm's case, I will again send the client back to Solicit if
there is a status code anywhere in the packet for NotOnLink.  I
think the only conformance requirement is to respond to a status
code in the message body...but obviously I think that runs some bad
risks...it's better guidance, I think, to search the packet.  Also,
Renew/Rebind behaviour (zeroed lifetimes) is intentionally not
accepted...it's ignored...in essence the contents of the packet
outside of the status code are ignored.  No configuration states are
updated, and no leases are extended (or reduced) to new lifetimes.
For conformance, I think this is required.

Again, not simple.  We wrote 469 lines of client code on the topic of
status code processing.  It's just about as complicated as it could
be. :(

-- 
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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Maverick <[email-masked]>
Date: Thu, 13 Sep 2007 12:14:04 +0530

One basic doubt.

As per the response:

In a scenario when the a single interface has multiple IP address.
And the client sends a confirm (including both the IA's)
One IP is on the link and the other is not. (could be that the admin deleted
on of the lesase.)

How should the server respond to this?

Thanks,
Maverick

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Sep 2007 08:24:20 -0700

> How should the server respond to this?

"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."

18.2.2.

So if any one address does not pass, you return a NotOnLink status,
and the client returns to Solicit.

The server may Advertise the address(es) which are still valid for the
link, and omit the invalid addresses, or it may Advertise all-new
addresses (particularly if the server thinks another client owns
them).  The client will Request whatever binding it prefers...it may
give greater weight to bindings that contain addresses it recognizes.