RE: [dhcwg] static route option for dhcpv6

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Martin Stiemerling
> Sent: Friday, January 18, 2002 1:50 PM
> To: Jim Bound
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] static route option for dhcpv6
> 
> 
> 
> 
> --On Donnerstag, Januar 17, 2002 12:29:00 -0500 Jim Bound 
> <seamus@bit-net.com> wrote:
> 
> > 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.
> 
> 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.

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.

> >
> > 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.
> 
> >
> > 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
> >
> >
> > On Thu, 17 Jan 2002, Vijay Bhaskar A K wrote:
> >
> >> 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
> >>
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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