Subject: Re: [dhcwg] Agenda for IETF-69 dhc WG meeting

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 24 Jul 2007 12:25:40 -0700 (PDT)

Comments in line.
Regards,

Behcet

----- Original Message ----
From: Ted Lemon <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 24, 2007 12:42:38 AM
Subject: Re: [dhcwg] Agenda for IETF-69 dhc WG meeting

On Mon, 2007-07-23 at 20:17 -0700, Behcet Sarikaya wrote:
> In RFC 3633, IAID is defined as 4 octet field to be the unique
> identifier for each IA_PD. 
> In view of per-Mobile Node prefix delegation, I suggest that we extend
> IAID to be 6 octets and use MAC address of MN for which the prefix is
> requested. This way the access router can keep track of each prefix it
> receives by associating the prefix with the MAC address. 

Why not make the IAID 16 octets, just in case we have a link with a
fatter address, or want to stuff a UUID in it or something?   Or we
could have it be arbitrrily long.

I don't mean to be sarcastic, but just to illustrate the problem with
this kind of thinking.   It really can't work.   The reason we chose a
four-byte IAID was to allow for a 32-bit interface index, not to allow
you to put a client-sourced identifier in it.

The question that comes to my mind with this proposal is, why not just
have the device that's getting the delegated prefix make the DHCP prefix
delegation request?   Why all this additional complexity?

[behcet] IPv6 address configuration requires the device to configure an address from the prefix in RA (router advertisement) or get it from DHCP. The device does not get the prefix directly.  It is the AR that should get it and create the point to point link.

[behcet] What I have proposed is that 32-bit interface index of IAID may probably need to be revisited because of this new application of DHCP PD which is client oriented.
It is up to you, just asking.

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 Jul 2007 16:26:00 -0400

Why doesn't the AR maintain a mapping between device and IAID (you could
use a hash of the remote device's identity - mac address or whatever -
and handle collisions appropriately).
 
We are NOT about to break existing implementations just because you want
the field bigger. As Ted already pointed out, others might want or need
larger fields.
 
The 4-byte IAID allows 4 billion PDs. That should be more than enough
for any application. So, if you can't stuff what you need into the
field, you'll have to develop a mapping scheme and maintain the mapping
table.
 
- Bernie

________________________________

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 3:26 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Agenda for IETF-69 dhc WG meeting

Comments in line.
Regards,

Behcet

----- Original Message ----
From: Ted Lemon <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 24, 2007 12:42:38 AM
Subject: Re: [dhcwg] Agenda for IETF-69 dhc WG meeting

[behcet] IPv6 address configuration requires the device to configure an
address from the prefix in RA (router advertisement) or get it from
DHCP. The device does not get the prefix directly.  It is the AR that
should get it and create the point to point link.

[behcet] What I have proposed is that 32-bit interface index of IAID may
probably need to be revisited because of this new application of DHCP PD
which is client oriented.
It is up to you, just asking.