Subject: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Apr 2004 16:44:27 +0300 (EEST)

Hi,

I glanced through draft-ietf-dhc-dhcpv6-ctep-opt-01.txt.  I also 
discussed this problem space with Vijay in IETF59.

I think the applicability and usefulness of this option is *very* 
questionable.

As it is a DHCPv6 option, it can be only used inside v6 sites with
basically their own DHCPv6 server in each.

That is, imagine that you wanted to connect 10 sites together from
their border router using full-mesh configured tunneling.  You'll have 
to set up 9 tunnels in each site, 9*10 tunnels in total.  

What's the gain of using DHCPv6 here, I ask?  You'll have to set up
these 9 tunnels in each of the 10 DHCPv6 servers in any case, 90
DHCPv6 configuration entries in total.  You're trading off having to
configure 90 tunnels in 10 border routers to having to configure 90
tunnels in 10 DHCPv6 servers.

IMHO, in this kind of set-up, Using DHCPv6 just doesn't seem to make 
sense.

Is there something I've missed?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Apr 2004 20:14:35 -0500

On Apr 2, 2004, at 7:44 AM, Pekka Savola wrote:
> You're trading off having to

Possibly it's easier to configure a DHCP server on a central server 
somewhere with all this information rather than configuring the router, 
because if the router dies then you have to remember to reconfigure it. 
   But basically, I don't know.   :')

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 Apr 2004 09:06:48 +0300 (EEST)

>    But basically, I don't know.   :')

You'll have to reconfigure the router in any case to get the other 
connectivity working ;-).

Here, you don't get aggregation benefits as you have to configure
exactly the same information in 10 DHCPv6 servers as you'd have to do
in 10 routers.  If you would only need to configure 1 DHCPv6 server to
get the config to all the routers, some folks might think this gives 
additional benefits.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Apr 2004 09:40:19 -0400

It is not be necessary to touch the router in all cases...

An IPv6 "home gateway" with a single upstream interface (to
the service provider) and one or more downstream interfaces
will operate in a sufficiently constrained environment so
as to allow plug-and-play operation with only minimal
configuration (such as a prefix delegated from the service
provider).  In this case, if the service provider makes IPv6
service available through a configured tunnel, the only other
configuration required would be the address of the other
endpoint of the tunnel.  It would make sense to provide
that endpoint address through DHCP along with the delegated
prefix.

Now, the dhc WG is debating whether or not to take on this
option as a WG work item, because it applies to router
configuration rather than host configuration.  The use
case is there - it's a matter of charter scope.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 16:53:37 +0300 (EEST)

> that endpoint address through DHCP along with the delegated

To be able to run DHCP*v6* between the CPE and the ISP, there has to
be IPv6 connectivity.  If there is no v6 connectivity, you cannot use
DHCPv6.  If there _is_ v6 connectivity, you do not need a configured
tunnel, because you already have v6 connectivity.

Am I missing something? 

(Or are you visualizing the scenario where there would be IPv6 
link-local connectivity, but for global connectivity, you would have 
to use a tunnel?  If so, could you describe a specific scenario as I 
fail to see where this would apply to?)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Apr 2004 10:21:53 -0400

Looks like I was missing something.  I confused
draft-ietf-dhc-dhcpv6-ctep-opt-01 with draft-daniel-dhc-ipv6in4-opt-02.  I
think my confusion arose because of the context of the conversation.  I had
understood draft-ietf-dhc-dhcpv6-ctep-opt-01 to be intended to inform a host
of a tunnel endpoint (which I think would normally be accomplished through
routing protocols) and draft-daniel-dhc-ipv6in4-opt-02 to talk about
configuring isolated routers with the endpoint of a tunnel.

My apologies for thoroughly confusing the conversation...

So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this discussion for
the moment.  Back to the scenario you asked about...I can imagine (if you'll
give me a moment of suspension-of-disbelief) that an ISP might want to
provide IPv6/linklocal service between the service provider's edge router
and the customer routers, without going to full IPv6 connectivity in its
core.  In that scenario, the customer router could use DHCPv6 to obtain a
prefix and a tunnel endpoint from a server in the service provider's edge
router, while needing the tunnel for full external IPv6 connectivity.

But that does seem like a far-fetched scenario...

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 17:51:03 +0300 (EEST)

> My apologies for thoroughly confusing the conversation...

No problem :)

> But that does seem like a far-fetched scenario...

Yes, it's very far-fetched, because in this specific scenario:

 1) the access network is usually the most difficult part to get 
native v6, and

 2) it's much simpler for all the concerned parties for the ISP to use 
internal tunneling to bridge the gaps in its core network.  Whether 
these tunnels are manually configured, set up automatically using 6PE 
("BGP-tunneling") between the border boxes, etc.  makes little 
difference.  It's very simple to provide v6 support across v4 core if 
your edge device supports v6 already.

So, as stated -- I'm having a lot of trouble figuring out the real 
applicability of this option, and I don't think we should go forward 
with it.  The danger is that it's more confusing than it's worth...

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 9 Apr 2004 12:38:47 -0400

I guess the solution is to ask the authors to add specific examples
of the environments in which this option will be used, if they still
feel
this option is needed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Friday, April 09, 2004 10:51 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01

No problem :)

> So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this discussion

> for the moment.  Back to the scenario you asked about...I can imagine 
> (if you'll give me a moment of suspension-of-disbelief) that an ISP 
> might want to provide IPv6/linklocal service between the service 
> provider's edge router and the customer routers, without going to full

> IPv6 connectivity in its core.  In that scenario, the customer router 
> could use DHCPv6 to obtain a prefix and a tunnel endpoint from a 
> server in the service provider's edge router, while needing the tunnel

> for full external IPv6 connectivity.
>

---

From: "S. Daniel Park" <[email-masked]>
Date: Sat, 10 Apr 2004 08:40:35 +0900

Ok, we need to make it more clear, so I will show
my thought soon whether or not to be considered
in the DHC.

Regards

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Volz
> Sent: Saturday, April 10, 2004 1:39 AM
> To: 'Pekka Savola'; 'Ralph Droms'
> Cc: [email-masked]
> Subject: RE: [dhcwg] applicability of 
> draft-ietf-dhc-dhcpv6-ctep-opt-01
> 
>

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 13 Apr 2004 12:29:04 +0900

>>>>> On Fri, 9 Apr 2004 17:51:03 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> with it.  The danger is that it's more confusing than it's worth...

FWIW, I tend to agree with you here.  But, apparently the authors are
now trying to clarify the applicability, so I'm open to listening to
it.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]