Subject: [dhcwg] One comment on draft-ietf-dhc-3315id-for-v4-05.txt

From: Andrea G Forte <[email-masked]>
Date: Thu, 10 Nov 2005 15:55:10 -0500

I have not followed the exchange of comments regarding this draft, so 
please forgive me if this issue has already been discussed. However, one 
comment I have is that this draft seems to be useful only if I have more 
than one network card on the same subnet (the change of chassis and/or 
the change of NIC are less common especially nowadays with more and more 
devices with built-in wireless/wired ethernet). In many cases, wireless 
and wired networks belong to different subnets, in such a case we would 
still have different IPs on different NICs, so the client would still 
appear as it has intermittent connectivity when switching from one to 
the other. Furthermore, if we have the two cards (wireless and wired) on 
the same subnet, using the same IP address on both would create a lot of 
problems if (for whatever reason) I decide to use both of the cards at 
the same time.

-Andrea

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Nov 2005 14:57:42 -0700

Actually, the point of the 3315id draft is to make sure that a DHCPv6 server 
and a DHCPv4 server that are updating the DNS can tell that they are doing 
the update on behalf of the same DHCP client.   It's also intended to be 
useful in similar contexts where there is some state about the DHCP client on 
a server, and the client is dual-stack, and we want to be able to have the 
server notice that a DHCPv4 and DHCPv6 client actually represent the same 
physical device.

As for the question of removable network interfaces, actually you will find 
that most of the "built in" network interfaces are in fact removable - for 
example I have a Sony VAIO laptop with a built-in 802.11g network device.   
However, if you screw off a little cover plate, you'll find that it's a 
mini-pci card, and can be removed.   Likewise, motherboards get swapped out, 
and when a system fails it's quite likely in any kind of corporate setting 
that the IT department would pull the drive from the system and plug it into 
a different system, with very quick turnaround.   In this case, a client 
following 3315id will see no change in its network connectivity, but a client 
that does not follow 3315id will lose its DNS registration for the remainder 
of its lease or for half the duration of its new lease, whichever comes last.

It's also the case that not all DHCP clients *have* MAC addresses.   If you 
read the RFCs for DHCP over infiniband and DHCP over firewire, you'll see 
that in those cases you do not have a unique identifier in chaddr/hlen.

As for the dual-interface, single wire scenario that you describe, that's 
actually not covered by 3315id, because it's too hard to specify, and not 
relevant to the purpose of 3315id.

I don't want to downplay the coolness of what you guys are doing - it is 
actually a very interesting idea, and it would be great if we could figure 
out how to make it work in the context of 3315id.   I don't think that's out 
of the question.   The point of the criticism is simply to identify a 
problem, so that a better solution can be worked out.

---

From: Andrea G Forte <[email-masked]>
Date: Thu, 10 Nov 2005 17:49:54 -0500

>problem, so that a better solution can be worked out.
Oh no I completely understand. My questions about 3315id were not 
related to the p-DAD proposal (and that is why I wrote a separate 
email), I was just trying to better understand your draft as I found it 
very interesting. That's all.
All comments and feedback are always very wellcome.

Going back to my question about 3315id, I guess what it is not clear to 
me is how does the DHCP client decide the IAID value for each interface? 
How does the DHCP client know if an application will simply switch 
between interfaces on the same wire (in this case I can use the same IP 
address/ same IAID to keep my identity and show continuous connectivity) 
or if it will use both interfaces on the same wire at the same time ( I 
use different IP/different IAID)?
Please know that I am much more familiar with DHCPv4 than DHCPv6.

-Andrea

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Nov 2005 17:27:33 -0700

> use different IP/different IAID)?

From the draft:

   DHCPv4 clients that support more than one network interface SHOULD
   use the same DUID on every interface.  DHCPv4 clients that support
   more than one network interface SHOULD use a different IAID on
   each interface.

The IAID is an opaque identifier, so as long as what the client does meets the 
requirements stated above, it's immaterial to the working of the protocol 
*how* the client picks the identifier.   Personally, I'd start at zero and 
add one for each new interface, or use the OS-supplied interface index.   
RFC3315 gives some guidance on consistency - it's good if the IAID for a 
given interface is the same across boots - but that's about it.

As to how an application would specify that it wanted the same IAID on both 
interfaces, I don't think an application ever would.   The only time I think 
it would make sense to present the same IAID on two interfaces would be a 
case where the operating system is prepared to treat the two interfaces as 
equivalent for routing purposes, so this is really an operating system 
integration issue, not an API issue, and in either case really wouldn't be 
appropriate to specify in this draft.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 11 Nov 2005 00:40:15 +0000

> add one for each new interface, or use the OS-supplied interface index.   

Funny, I noticed that the IAID was 4 bytes, and most interface ID's in
unixland were four-ish (fxp0, eth0, ...), and immediately drew a
conclusion.

It all works.

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