Subject: Reducing the DHCPv6 packet size?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 14 Mar 2001 08:37:42 -0600

A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ...

Do we really need to carry the client-link-local-address in most Client/Server interactions?

1) The relay or server on the local link can simply use the source address of the packet.
2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet.
3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet.
4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum).

What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable.

All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not).

So, the proposed new headers would be:

   The DHCP message header:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Relay-forward/Relay-reply message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                   client-link-local-address                   |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Bernie Volz
  Ericsson

---

From: [email-masked]
Date: Wed, 14 Mar 2001 09:35:28 -0600

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes)
... 

Do we really need to carry the client-link-local-address in most
Client/Server interactions? 
[JPB2] I think absolutely.   

1) The relay or server on the local link can simply use the source address
of the packet. 
[JPB2] We were down this path.  Doing this requires me to used the v6
advanced api or sysct or confget sys call. 
2) A relay will need to include the client-link-local-address when it sends
a Relay-Forward to a server, but that can be added into the relay's packet.
[JPB2] we want to reduce the execution of code path on relays when ever
possible. mv or copy is faster than read header and extract. 

3) A server will need to include the client-link-local-address when it sends
a Relay-Reply to a server, but that again can be added into the relay's
packet.
[JPB2] This adds new state to our new relay paradigm and more code as above.

4) If authentication (of whatever type) wants to cover the
client-link-local-address, that can be added to some pseudo-header (much
like TCP and UDP have the source and destination address in the
pseudo-header when they calculate the checksum).
[JPB2] exactly and like tcp and udp the addresses are in the packet data not
the header on any psuedo checksum I have worked on v4 or v6 and old DECnet
and SNA.  The link-local is inherent to IPv6 we must have it. 

What this means is that client <--> agent interactions would save 16
bytes/packet and the Relay <--> server interaction packets would be the same
size. For 3GPP/UMTS networks, this would save bytes over the air interface
which is desireable.
[JPB2] Well if start trying to save bytes for 3gpp we then go back to the
original dhcpv6 msg formats and I think we decided that dhcp is a control
protocol.   also compression will be used in 3gpp at the radio, relay, sgsn,
and ggsn interface logical units. 

All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address
of a packet on a receive operation (such as socket's recvfrom). And, I can't
imagine that the address selection logic for IPv6 would ever suggest using a
non-link-local address for the IPv6 header source address if the destination
address is a link-local-address (whether multicast or not).

   The DHCP message header: 

      0                   1                   2                   3 

      0                   1                   2                   3 

- Bernie Volz 
  Ericsson 
[JPB2] I don't believe your arguments are strong enough to change the spec.
There is a reason why we are here today.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 14 Mar 2001 14:27:16 -0600

Jim ... see BV> below. However, you might want to first read this:

I want to understand the fundamental reason why we have to put it in the DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there (based on today). My suggestion was based on the -18 draft where the client always sent packets to the link-local multicast address for the All DHCP Agents address. HOWEVER, if we allow the client to unicast (or even multicast to other than a link-local address), the client's IPv6 header (source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we did discuss today in the conference call) to allowing the client to communicate directly with an off-link server, I *MUST* withdraw this. I should probably have made that clear in my original message (it assumed the -18 draft behavior).
 
So, based on today's discussion and Design Team preference to change the client sending behavior, we can drop this request.
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 10:35 AM
To: DHCPv6 discussion list
Subject: RE: Reducing the DHCPv6 packet size?

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

1) The relay or server on the local link can simply use the source address of the packet. 
[JPB2] We were down this path.  Doing this requires me to used the v6 advanced api or sysct or confget sys call . 

BV> No, recvfrom always returns the source address. So, you get it without doing anything special. What recvfrom does NOT return is the destination address for the datagram (and that is at least with IPv4 a pain to get).

2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet.
[JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract.  

BV> Jim, it's already adding other stuff in forming the relay packet, this isn't a big deal (copy 16-bytes from the recvfrom source-address structure). 

BV> No, it really doesn't. The server can simply get this out of the Relay-Forward packet it received. 

4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum).
[JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA.  The link-local is inherent to IPv6 we must have it.  

BV> Yes, the addresses are in the *IP* packet header but they are not in the *TCP* and *UDP* packet header. This is exactly the same model I'm proposing. The client's link-layer address is already in the *IP* header. Why duplicate this in the datagram (you're just sending it twice in the packet).

What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable.
[JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol.   also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units.  

BV> It isn't just for 3GPP - think of dial-up and other links that might use DHCP that have limited bandwidth capabilities. Great if compression is used; but you'll save more by not having it there in the first place. 

   The DHCP message header: 

      0                   1                   2                   3 

      0                   1                   2                   3 

- Bernie Volz 
  Ericsson 
[JPB2] I don't believe your arguments are strong enough to change the spec.  There is a reason why we are here today.

---

From: [email-masked]
Date: Wed, 14 Mar 2001 21:45:54 -0600

Bernie,
 
just as note rather than beating this dead horse.  rcvfrom is not good
enough for the relay.  The relay needs to know what interface the packet
came in on too.  sendmsg with the v6 advanced api can do this was my point.
but if we have to revisit this again I have other performance reasons.  but
will drop them for now.  the relay could get then interface index too via
the base api and then compare the address from dst addr which is possible.
But the relay has to send the packet out the interface to the client on
which it came from is where I was going.
 
Your right I can always extract it from the header.  But we were told to put
the datums in the protocol whenever possible.  I am not arguing how we get
it.  Just that I want it.
 
On saving bytes.  If that is our goal there are lots of places to do that.
Not sure its our goal now?
The reason I used 3gpp and not dial up lines et al.  Is that the first
deployment will be 3gpp and kind of on my mind as its  a real IPv6 market I
can taste which does bias my responses....I am also not against saving
bytes.  I am against changing our mind a lot at this point.  We have a path.
Lets follow it. If its bogus we will find out real quick.
 
thanks
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday,March 14,2001 3:27 PM
To: [email-masked]'; [email-masked]'
Subject: RE: Reducing the DHCPv6 packet size?

I want to understand the fundamental reason why we have to put it in the
DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there
(based on today). My suggestion was based on the -18 draft where the client
always sent packets to the link-local multicast address for the All DHCP
Agents address. HOWEVER, if we allow the client to unicast (or even
multicast to other than a link-local address), the client's IPv6 header
(source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination
is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we
did discuss today in the conference call) to allowing the client to
communicate directly with an off-link server, I *MUST* withdraw this. I
should probably have made that clear in my original message (it assumed the
-18 draft behavior).
 
So, based on today's discussion and Design Team preference to change the
client sending behavior, we can drop this request.
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 10:35 AM
To: DHCPv6 discussion list
Subject: RE: Reducing the DHCPv6 packet size?

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

1) The relay or server on the local link can simply use the source address
of the packet. 
[JPB2] We were down this path.  Doing this requires me to used the v6
advanced api or sysct or confget sys call . 

BV> No, recvfrom always returns the source address. So, you get it without
doing anything special. What recvfrom does NOT return is the destination
address for the datagram (and that is at least with IPv4 a pain to get).

BV> Jim, it's already adding other stuff in forming the relay packet, this
isn't a big deal (copy 16-bytes from the recvfrom source-address structure).

BV> No, it really doesn't. The server can simply get this out of the
Relay-Forward packet it received. 

BV> Yes, the addresses are in the *IP* packet header but they are not in the
*TCP* and *UDP* packet header. This is exactly the same model I'm proposing.
The client's link-layer address is already in the *IP* header. Why duplicate
this in the datagram (you're just sending it twice in the packet).

BV> It isn't just for 3GPP - think of dial-up and other links that might use
DHCP that have limited bandwidth capabilities. Great if compression is used;
but you'll save more by not having it there in the first place. 

   The DHCP message header: 

      0                   1                   2                   3 

      0                   1                   2                   3 

- Bernie Volz 
  Ericsson