Re: [dhcwg] static route option for dhcpv6

Vijay Bhaskar A K <vijayak@india.hp.com> Thu, 17 January 2002 13:04 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13958 for <dhcwg-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:04:53 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00797 for dhcwg-archive@odin.ietf.org; Thu, 17 Jan 2002 08:04:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29851; Thu, 17 Jan 2002 07:45:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29825 for <dhcwg@optimus.ietf.org>; Thu, 17 Jan 2002 07:44:59 -0500 (EST)
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13435 for <dhcwg@ietf.org>; Thu, 17 Jan 2002 07:44:56 -0500 (EST)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel11.hp.com (Postfix) with ESMTP id 81124E0069E; Thu, 17 Jan 2002 04:44:15 -0800 (PST)
Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA12123; Thu, 17 Jan 2002 18:18:32 +0530 (IST)
From: Vijay Bhaskar A K <vijayak@india.hp.com>
Message-Id: <200201171248.SAA12123@dce.india.hp.com>
Subject: Re: [dhcwg] static route option for dhcpv6
To: Bernie.Volz@am1.ericsson.se
Date: Thu, 17 Jan 2002 18:18:31 +0530 (IST)
Cc: vijayak@india.hp.com, dhcwg@ietf.org
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD99@EAMBUNT705> from Bernie Volz at Jan "16, " 2002 "01:17:09" pm
X-Mailer: ELM [$Revision: 1.17.214.2 $]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

Please see my comments inline.

~Vijay.

> 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.

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.

>  
> 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 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.

>  
> I myself am leaning more towards recommending we wait until a need is found.
>  
> - Bernie
>  
> 
> -----Original Message-----
> From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, January 16, 2002 1:13 PM
> To: 'Bernie Volz (EUD)'; dhcwg@ietf.org
> Subject: RE: [dhcwg] static route option for dhcpv6
> 
> 
> Bernie,
> This option format looks ok for me. We can include it.
> Vijay
> 


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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg