Subject: RE: [dhcwg] static route option for dhcpv6

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 16 Jan 2002 13:17:09 -0600

After thinking about this more and after seeing the other discussion on this subject, I'm not sure exactly when or why this option would be needed. But on the other than, it technically isn't needed in IPv4 either because ICMP redirects and other routing table distribution techniques exist and DHCPv4 does have such an option (and a revised one to carry classless routes).
 
So, we can do one of two things:
1. Include it and consider DHCPv6 as a toolbox and those people that want to use it (and those clients that want to support it) do so. For example, Solaris 8 includes the route command and it supports IPv6 routing table operations. Can anyone who has lots of experience with IPv6 deployment indicate whether there is a need to statically add routing table entries?
2. Wait until someone has a clear case of needing it and have it defined in some future document.
 
If we do want to include it, questions to ponder:
- Should any lifetimes be associated with the routes? Either one lifetime for all routes or each route?
- Should this option be encapsulated within an IA? That way, it would be renewed with the IA.
 
I myself am leaning more towards recommending we wait until a need is found.
 
- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 1:13 PM
To: 'Bernie Volz (EUD)'; [email-masked]
Subject: RE: [dhcwg] static route option for dhcpv6

Bernie,
This option format looks ok for me. We can include it.
Vijay

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 17 Jan 2002 12:18:35 +0100

Hi,

comments are inline.

--On Mittwoch, Januar 16, 2002 13:17:09 -0600 "Bernie Volz (EUD)" 
<[email-masked]> wrote:

>
> After thinking about this more and after seeing the other discussion on
> this subject, I'm not sure exactly when or why this option would be

I'm not sure, too. But I would be happy if Vijay could make a small picture 
with the scenario his thinking of to get a clear view.

> needed. But on the other than, it technically isn't needed in IPv4 either
> because ICMP redirects and other routing table distribution techniques
> exist and DHCPv4 does have such an option (and a revised one to carry
> classless routes).
> 1. Include it and consider DHCPv6 as a toolbox and those people that want
> to use it (and those clients that want to support it) do so. For example,
> Solaris 8 includes the route command and it supports IPv6 routing table
> operations. Can anyone who has lots of experience with IPv6 deployment
> indicate whether there is a need to statically add routing table entries?

I do the IPv6 deployment for a complete site, and I haven't encounter such 
a situation where a host needs a static route. But I'm willing to learn.

> 2. Wait until someone has a clear case of needing it and have it defined

I prefer this way.

Martin

> - Should any lifetimes be associated with the routes? Either one lifetime
> for all routes or each route?  - Should this option be encapsulated
> within an IA? That way, it would be renewed with the IA.

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

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 17 Jan 2002 18:18:31 +0530 (IST)

Please see my comments inline.

~Vijay.

> 2. Wait until someone has a clear case of needing it and have it defined in some future document.

Assume the following scenaria.
- There are 2 networks A and B.
- There is a node n connected  to both the  network,  and it has enabled
ipv6-forwarding and not sending router advertisements.

Now, a node in network A gets an address from the DHCPv6  server and now
it  wants  to  communicate  with a node in  network  B.  In the  current
scenario, the route has to be manually configured, then only, it will be
able to contact the node in network B.  With static route option, we can
autoconfigure   it.  This  will  be  more  helpful  in  getting  minimal
configuration   for  smaller  networks,  which  don't  have  any  router
advertisements  and for the networks which have not completely  deployed
routing mechanisms.

It will be useful in the getting the configured tunnels also.

> - Should this option be encapsulated within an IA? That way, it would be renewed with the IA.

I think, we can treat this as another configuration parameter.  We don't
need to mix up with IA.  If there are  multiple  IAs with  same  prefix,
then this static route is common for all these IAs.  Whenever there is a
change in the  static  route, we can use  reconfiguration  mechanism  to
update it.

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
______Ph:_2051424________
____Telnet:_847_1424_____
___Pager:_9624_371137____

---

From: Jim Bound <[email-masked]>
Date: Thu, 17 Jan 2002 12:29:00 -0500 (EST)

We need the static route option for the dentist office scenarios of IPv6
where there are two lans and no routers or as VJ pointed out ipv6forwardin
g is turned on and not doing RAs.

We also want it for configured tunnels and its different than DSTM.

We should also keep it simple as a config parameter.

I see no pain here and it is needed.  Its a simple option to add and
necessary for early IPv6 deployment as VJ pointed out in first mails.

regards,

/jim

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 18 Jan 2002 09:20:23 +0100

> g is turned on and not doing RAs.

But doesn't an IPv6 router that isn't sending his router advertisements 
violate the IPv6 spec? In this case DHCPv6 should not support this feature 
in this way.

> We also want it for configured tunnels and its different than DSTM.

Ok, I agree with using it for configured tunnels. But I would choose 
another name, like IPv4 Tunnel End Point.

> We should also keep it simple as a config parameter.

Yes.

>> > After thinking about this more and after seeing the other discussion
>> > on this subject, I'm not sure exactly when or why this option would be
>> > needed. But on the other than, it technically isn't needed in IPv4
>> > either because ICMP redirects and other routing table distribution
>> > techniques exist and DHCPv4 does have such an option (and a revised
>> > one to carry classless routes).
>> >
>> > 1. Include it and consider DHCPv6 as a toolbox and those people that
>> > want to use it (and those clients that want to support it) do so. For
>> > example, Solaris 8 includes the route command and it supports IPv6
>> > routing table operations. Can anyone who has lots of experience with
>> > IPv6 deployment indicate whether there is a need to statically add
>> > routing table entries? 2. Wait until someone has a clear case of
>> > needing it and have it defined in some future document.
>>
>> > - Should any lifetimes be associated with the routes? Either one
>> > lifetime for all routes or each route? - Should this option be
>> > encapsulated within an IA? That way, it would be renewed with the IA.
>>

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Fri, 18 Jan 2002 23:35:09 +0530

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Martin Stiemerling
> Sent: Friday, January 18, 2002 1:50 PM
> To: Jim Bound
> Cc: [email-masked]
> Subject: Re: [dhcwg] static route option for dhcpv6
> 
> 
> 
> 

Please note that, there are no routers in the networks. That's why
i mentioned that node as the one conneceted to two network and having
ipv6forwarding enabled, instead of routers. This is for the networks
which have not deployed IPv6 routing completely. I think there is no
harm in having this option.

> >> > I myself am leaning more towards recommending we wait 
> until a need is
> >> > found.
> >> >
> >> > - Bernie
> >> >
> >> >

---

From: John Schnizlein <[email-masked]>
Date: Fri, 18 Jan 2002 15:22:36 -0500

>harm in having this option.

If the purpose of the option is to enable situations where hosts
have ipv6forwarding enabled, but do not act as proper v6 routers,
then we should not support it. That is just bad practice. (IMHO)
The use for tunnelling might be justifiable.

John

---

From: Jim Bound <[email-masked]>
Date: Fri, 18 Jan 2002 16:40:54 -0500 (EST)

> violate the IPv6 spec? In this case DHCPv6 should not support this feature 

THere are no routers in the dentist office scenario.  Inn this scenario
the nodes use all link-local addresses.   This is also a reason why
stateful IPv6 address configuration is needed ala dhcpv6.  A router that
does send RAs may not send necessary static routes.  Like a server that
sets the isarouter variable and only sends prefix RAs for configuration.
I need to check the spec though thats a good point.  I don't think ND
mandates a router must do this.  It should not IMO as it may want to let
another router send RAs for routing but not addr conf.

/jim

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 21 Jan 2002 09:26:41 +0100

> then we should not support it. That is just bad practice. (IMHO)

I totaly agree with this.

> The use for tunnelling might be justifiable.

This is, what I have mentioned some emails before. Give the child the 
proper name and it is OK.

Martin