[BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03

Hi Dave and Suresh,

Thanks a lot for your valuable information. 

>From the following two drafts, it can be easily concluded that both DHCPv6
and RA have their own markets. The harassment to ISPs is they had to use
these two mechanisms together in some cases because some option defined in
one mechanism has no counterpart in the other one. Either the DHCP carrier
option in RA or the default router option (even the possible RA carrier
option) in DHCPv6 is to deal with the above problem. To avoid redundant
standardization effort, except the idea of DHCP (or RA) carrier option,
another possible way is to unify their TLVs of common options for both RA
and DHCPv6, especially the TLV of a new option (e.g., the prefix64 option),
although the length of their Type/Length field is different from each other
unfortunately.

+++++++++++Some quotes from the following two drafts, 
+++++++++++FYI.++++++++++++++++

In http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00, there was a
statement as "... Recently there has been interest in doing more of DHCP
work using   Neighbor Discovery (Router Advertisement) messages.  This is
mainly to accomodate environments where DHCP is not available and the only
way of convey configuration information is through RAs."

In http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00,
there was a statement as " In many IPv6 deployments, particularly in edge
networks, end devices obtain configuration information about default
routers, on-link   prefixes and addresses from Router Advertisements as
defined in Neighbor Discovery.  In some deployments, however, there is a
strong desire not to use Router Advertisements at all and to perform all
configuration via DHCP [RFC3315]."
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Xiaohu

> -----邮件原件-----
> 发件人: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]
> 发送时间: 2009年8月20日 3:47
> 收件人: Dave Thaler
> 抄送: Xu Xiaohu; 'Behave WG'
> 主题: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03
> 
> Hi Dave,
>    Here is a pointer to that doc.
> 
> http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00
> 
> I did not update this document further since there was a possibility of
> redundant (and potentially conflicting) information being passed thru
> this mechanism and dhcpv6 (Section 2.3 of RFC5505) and I did not know
> how to reconcile these pieces of info on the host.
> 
> Cheers
> Suresh
> 
> On 09-08-19 03:35 PM, Dave Thaler wrote:
> > There was discussion in the intarea meeting at IETF 74.
> >
> > Minutes: http://www.ietf.org/proceedings/74/minutes/intarea.txt
> > Slides: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf
> >
> > The discussion concluded by saying that defining an RA option that can
> > contain DHCP options seems like a good idea.  E.g. from the minutes:
> > "- Krishnan: Pointing out that he wrote a spec on how to share options
between
> DHCP and RA's."
> >
> > Perhaps Suresh can provide more info here.
> >
> > -Dave
> >
> >> -----Original Message-----
> >> From: Xu Xiaohu [mailto:xuxh@huawei.com]
> >> Sent: Tuesday, August 04, 2009 6:24 PM
> >> To: Dave Thaler; 'Behave WG'
> >> Subject: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03
> >>
> >> Hi Dave,
> >>
> >>> 4) If there are folks (not me) that really believe in RA
> >> configuration
> >>>    for information that the local router isn't authoritative for,
> >>>    there's already interest in defining an RA option that can contain
> >>>    DHCP options so you don't have to define RA options for
> >>> all of them.
> >> Defining an RA option that can contains DHCP options directly seems a
> >> good
> >> idea. Could you please provide any detailed clues?
> >>
> >> Thanks,
> >>
> >> Xiaohu
> >>
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave