Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Feb 2004 10:36:12 -0500

I think this document is ready to be accepted as dhc WG work item.

Making this option a DHCPv4 option allows a dual stack host to bootstrap
itself into a disconnected IPv6 infrastructure - for example, a dual-stack
host on an IPv4-only link.

- Ralph

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Feb 2004 16:43:07 -0500

Hi:

Some comments on daniel-dhc-ipv6in4-opt-01.txt (I hope this is the latest):

- What exactly is the subnet mask used for? I don't understand why this
field is present for each address. The address is a IPv4 destination address
of the router (or host) to which IPv6 packets can be tunneled over IPv4 and
I see no reason why a subnet mask is needed (a single address serves as the
tunnel, not an entire subnet?).

Perhaps this was supposed to be IPv6 network information (address + prefix
length)? But from what RFC 2893 says, this doesn't make sense either since
this is supposed to be a last resort route. This is partially reinforced in
section 4 of the draft:

     The list of end-points can be installed as the default routes and 
     the routes will be tried in a round robin fashion if the IPv6 host 
     load-sharing is honored [5].  Instead there can be specific default 
     routes for the different destination.

But, the last sentence is troublesome as how can specific default routes be
installed for different destinations (unless IPv6 information is somehow
communicated).

I think what you might want for each tunnel endpoint is:
	- IPv4 address of the tunnel endpoint
	- IPv6 address and prefix-length for the IPv6 network reachable
through the tunnel.

Encoding this could be done in a variable number of bytes:
	- IPv4 address is fixed 4-bytes
	- IPv6 prefix-length is 1 byte
	- IPv6 address is from 0 to 16 bytes depending on length.

For the more likely last resort routes (for all non-local IPv6 traffic),
you'd only use 5 bytes - 4 for IPv4 address and 1 for prefix-length of 0.

- If the subnet mask is needed:

a. "The minimum length of this option is 4, and the length MUST be a
multiple of 4" is incorrect as it should be 8 and multiple of 8.

b. It might be better if 5 bytes were used to represent this - address
followed by a subnet length. This is a more compact form and will keep
packet sizes down.

Hopefully I'm completely confused. And if so, that might also point out
something about the draft? Perhaps references to [4] should have an explicit
section number to help? Or the terminology should be consistent ... [4] uses
"Configured tunneling of IPv6 over IPv4", this draft uses different
language, "IPv6-in-IPv4 configured tunnel".

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph
Droms
Sent: Tuesday, February 24, 2004 10:36 AM
To: [email-masked]
Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Feb 2004 16:52:52 -0500

Bernie - I think you're exactly right, each entry should include:

* IPv4 tunnel endpoint address
* IPv6 prefix length
* IPv6 prefix

The receiving host encapsulates and forwards any IPv6 datagrams that match
the IPv6 prefix in an IPv4 datagram sent to the IPv4 tunnel endpoint address.

I also agree that we might consider carrying the IPv6 prefix as a variable
length data item, with the length as required by the prefix length.

- Ralph

---

From: "S. Daniel Park" <[email-masked]>
Date: Wed, 25 Feb 2004 09:56:35 +0900

Thanks for letting me consider these !
All what indicated by Bernie is reasonable and I'll
make sure the changes end up in the next draft.

PS: Don't we need a tuples to installl the routes on the client 
like < Prefix/prefix-len, Configured TEP IPv4 Address > ?

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, February 25, 2004 6:53 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments
> 
>

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Feb 2004 20:23:55 -0500

Hi:

Not sure exactly what you mean, but yes for each configured tunnel endpoint
you need three items (a tuple):
	- IPv4 address of the tunnel endpoint (4-bytes)
	- IPv6 prefix length for the IPv6 route to the tunnel endpoint
(1-byte)
	- IPv6 prefix for the route ... (prefix length/8 bytes)
When the prefix length is 0, no prefix is needed (since it is 0). You can
put them in any order you like, but to compress the information, you'll need
to put the prefix length before the prefix.

Are the prefix length and prefix really needed? Will routing information
(RAs) arrive over the tunnel that might already supply this (and thus avoid
the need for configuration through DHCPv4)? If multiple tunnels exist, one
could assume they are like IPv4 default routes and the routing information
should eventually get sorted out such that the proper tunnel is used?
(Ralph's comment regarding the DHCPv6 tunneling option draft made we wonder
about this issue here as well.)

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S.
Daniel Park
Sent: Tuesday, February 24, 2004 7:57 PM
To: 'Ralph Droms'; [email-masked]
Cc: [email-masked]; 'S. Daniel Park'; Bernie Volz
Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments

Regards

> Behalf Of Ralph

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 24 Feb 2004 21:49:30 -0500

Can anyone point me to an OS or application that actually uses DHCPINFORM?

--kan--

---

From: "S. Daniel Park" <[email-masked]>
Date: Wed, 25 Feb 2004 15:19:38 +0900

> When the prefix length is 0, no prefix is needed (since it is 
> 0). You can put them in any order you like, but to compress the 
> information, you'll need to put the prefix length before the prefix.

Yes, that's my assumption !

> Are the prefix length and prefix really needed? Will routing 
> information (RAs) arrive over the tunnel that might already 
> supply this (and thus avoid the need for configuration through 
> DHCPv4)? If multiple tunnels exist, one could assume they are 
> like IPv4 default routes and the routing information
> (Ralph's comment regarding the DHCPv6 tunneling option draft 
> made we wonder about this issue here as well.)

I will let you know on that in the next response.
It should be deeply considered on both drafts of course.

Regards