dhc WG meeting summay

There was a proposal at the meeting to rename the
Relay Agent Assignment Notification (RAAN) option
as the Classless Static Route (CSR) option for
DHCPv6 (i.e., the DHCPv6-equivalnet of RFC3442),
and it was suggested to take the discussion to
the list. Reasons to rename the option include:

  1) symmetry with DHCPv4
  2) promote existing DHCPv4 option to DHCPv6 
  3) simplify documentation ("CSR" used for
     both DHCPv6; DHCPv4)

As an example of a document that is simplified by
using the same term (CSR) to identify both the
DHCPv4 and DHCPv6 options, see:

http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
4.txt

Comments?

Fred
fred.l.templinboeing.com 

-----Original Message-----
From: Ralph Droms [mailto:rdromscisco.com] 
Sent: Monday, November 13, 2006 5:42 AM
To: dhcwg
Cc: Stig Venaas
Subject: [dhcwg] dhc WG meeting summay

Included below is a summary of the WG meeting and document
actions taken
during the meeting.  Please review and reply with comments
by Fri, Nov
17.
If there are no comments, we will begin confirming the
document actions
on
the WG mailing list next week.

- Ralph


                           dhc WG meeting summary
                                 Nov 8, 2006

Draft last call and adoption announcements

WG last call:
draft-ietf-dhc-dhcpv6-agentopt-delegate-01
draft-volz-dhc-dhcpv6-srsn-option-00

  These two drafts will be submitted as a package to IESG.
  draft-volz-dhc-dhcpv6-srsn-option-00 was accepted as a WG
work item
  on Oct 27.
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list after draft-volz-dhc-dhcpv6-srsn-option-00 is
  republished as dhc WG work item
draft-ietf-dhc-dhcpv6-srsn-option-00

draft-ietf-dhc-dhcpv6-reconfigure-rebind-00
  Clarifies text in 3315 about where client sends response
to
  Reconfigure, and that Reconfigure message can cause client
to send
  Rebind as well as Renew.  To be written as new RFC
updating RFC 3315
  rather than as an errata.
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list

draft-ietf-dhc-subnet-alloc-04
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list; concerns about IPR statement to be addressed
during WG
  last call

draft-ietf-dhc-dhcpv6-ero-00
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list

draft-ietf-dhc-failover-12.txt
  After a long period of inactivity, interest in moving I-D
forward
  expressed from 3 sources independently.  Interested
parties to meet
  after WG meeting to form ad hoc design team to develop an
action
  plan.

WG rechartering
  WG chairs have updated charter.  No objections to charter
during
  brief review in WG meeting.  WG to discuss revised charter
on WG
  mailing list.

draft-daniel-dhc-mihis-opt-02
  Need to confirm with IEEE 802.21 about need for this
option and
  about design in IEEE 802.21 WG.

draft-ietf-dhc-dhcvp6-leasequery-00
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list.

draft-stenberg-pd-route-maintenance-00
  Further discussion needed

draft-volz-dhc-dhcpv6-srsn-option-00
  Consensus in the room to go to WG last call; to be
confirmed on WG
  mailing list.
 
draft-templin-autoconf-netlmm-dhcp-04
  No WG action; WG members encouraged to attend netlmm WG
meeting

draft-ietf-dhc-pxelinux-00
  Consensus in the room to go to WG last call for
Informational RFC;
  to be confirmed on WG mailing list.

draft-dhankins-atomic-dhcp-00
  Consensus in the room to take on this draft as a WG work
item
  (Informational RFC); to be confirmed on WG mailing list.

draft-joshi-dhcp-lease-query-ext-02
draft-decnodder-dhc-rai-unicast-01
  No consensus to take on these drafts as WG work item at
this time.

draft-sarikaya-dhc-proxyagent-00
  No consensus to take on this draft as WG work item at this
time.

draft-fujisaki-dhc-addr-select-opt-02
  Need to wait for work in v6ops before taking on design of
this
  option in dhc WG

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

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

On Mon, Nov 13, 2006 at 10:30:27AM -0800, Templin, Fred L
wrote:
> As an example of a document that is simplified by
> using the same term (CSR) to identify both the
> DHCPv4 and DHCPv6 options, see:
> 
> http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
> 4.txt

Unless I am completely mistaken, this documents Mobile Nodes
(MN) as DHCPv4 and DHCPv6 "Clients".  Access
Routers (AR)
as DHCPv4 and DHCPv6 "Relays".

It is the AR's which wish to consume the "CSR" as
defined in
your draft?

It's a bit strange already that you're suggesting a DHCPv4
relay
would 'snoop' packet contents intended by the server for the
client.

> Comments?

Well, go ahead, give me an excuse why don't you?


RAAN was really intended for relay agents, and the document
does detail that this option is to be included at the 'relay
reply' level only...it goes into some detail...including
requiring the DHCP server to submit the option to the relay
in its reply to a release message (again at the relay-reply
level), with zeroed lifetimes.  Effectively instructing the
relay to remove the route.  This is, in my opinion, *not*
elevating DHCPv4 CSR to DHCPv6.

It is more similar to elevating IPv4 RIP to DHCPv6, but
still
different enough not to make that comparison entirely fair.

The CSR routes used for clients in DHCPv4 were substantially
more 'informative'.  The RAAN is much more 'programmatic'.
The implementation requirements are substantially different.

It certainly isn't expected for DHCPv4 clients to populate
an
ACL or to propogate the routes received, and I would be
concerned if there were any suggestion a client should do
so,
or that a relay should propogate routes 'advertised' in a
packet it witnessess to be bound for a client.


I don't think we're looking at exhausting the 16-bit option
space anytime soon.  So I would suggest making these two use
cases two different options.

The intent being to make the implementation details on those
clients that consume "CSR" information far more
lenient and
optional than is required for the relay's use case in RAAN,
not the least of which I would hope is to remove all mention
of propogating routes.


In summary, you're looking for a DHCPv4 RAAN, if I understad
your document correctly, not a DHCPv6 CSR.


I'm also equally skeptical about that as I have been about
RAAN.  These are routing problems being solved with a
configuration protocol.

It would be nice if an actual routing protocol could be
used,
possibly /configured/ into operation via DHCPvX.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Hi David, 

Cutting down a bit:

>>
http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
>> 4.txt
>
> Unless I am completely mistaken, this documents Mobile
Nodes
> (MN) as DHCPv4 and DHCPv6 "Clients".  Access
Routers (AR)
> as DHCPv4 and DHCPv6 "Relays".

Right, but the ARs also configure DHCP clients that speak
to the server on behalf of MNs that have recently departed
and/or MNs that do not use DHCP themselves.

> It is the AR's which wish to consume the
"CSR" as defined in
> your draft?

Yes.

> It's a bit strange already that you're suggesting a
DHCPv4 relay
> would 'snoop' packet contents intended by the server
for the
> client.

The way the draft is currently specified, it is true that
the DHCPv4 relay is expected to 'snoop' packet contents
for the case of adding routes. But, if we wanted a totally
unmodified relay the MAP could do a FORCERENEW/INFORM/REPLY
exchange with the AR's client function with CSRs containing
routes to be added, i.e., we could make it symmetric with
the route deletion case.

> RAAN was really intended for relay agents, and the
document
> does detail that this option is to be included at the
'relay
> reply' level only...it goes into some
detail...including
> requiring the DHCP server to submit the option to the
relay
> in its reply to a release message (again at the
relay-reply
> level), with zeroed lifetimes.  Effectively instructing
the
> relay to remove the route.  This is, in my opinion,
*not*
> elevating DHCPv4 CSR to DHCPv6.

Well, DHCPv4 CSRs carry (address/prefixlen, nexthop)-tuples
and DHCPv6 RAANs carry addresses and/or prefixes with with
associated lifetimes so there are differences. But, both are
used for the purpose of configuring routing information in
the network equipment associated with the entity that
processes
the options. It seems safe to call them "static
routes" because
no routing protocol is involved. It also seems safe to call
them "classless static routes" since there is no
longer any
"classful" netmask associated with IPv4 addresses
and there
never was any associated with IPv6 addresses.   

> In summary, you're looking for a DHCPv4 RAAN, if I
understad
> your document correctly, not a DHCPv6 CSR.

I'll agree that it would be preferrable if IPv4 offered
an option for carrying routing information that could be
inserted by servers and received by relay agents. That
would make for a clean separation of function in which
the client is responsible for reliable message exchanges
and the relay is responsible for managing routes in its
associated networking equipment. But, there are problems
with this when the client and relay reside on the same
device which I will bring up in a separate message.   

> I'm also equally skeptical about that as I have been
about
> RAAN.  These are routing problems being solved with a
> configuration protocol.
>
> It would be nice if an actual routing protocol could be
used,
> possibly /configured/ into operation via DHCPvX.

There are good reasons to avoid using a routing protocol
in the environment I am concerned with. If there is a
stable aggregation point (or points) inside an operator's
network and many MNs moving about frequently between ARs,
we want to avoid injecting MN-specific routes into the
IGP so that routing churn and IGP convergence latency is
avoided. We can do that if we can confine per-MN routing
updates to just the aggregation points and as side-effect
of the DHCP Solicit/Confirm/Renew/Rebind/etc procedures.

Thanks - Fred
fred.l.templinboeing.com

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

On Mon, Nov 13, 2006 at 04:03:49PM -0800, Templin, Fred L
wrote:
> Right, but the ARs also configure DHCP clients that
speak
> to the server on behalf of MNs that have recently
departed
> and/or MNs that do not use DHCP themselves.

That's right, you had relays that had colocated clients.  I
can see how this would create some confusion.

But I still think you're after a DHCPv4 RAAN, and have in
your
contrived situation determined to use the CSR for this
purpose.

That is, I think everyone who isn't colocating relays with
their
clients will have the opposite naming problem.

> the options. It seems safe to call them "static
routes" because
> no routing protocol is involved. It also seems safe to
call

That's not true.  The DHCPv6 RAAN draft explicitly states,
in section 3, 'Option Semantics':

   Examples of use:

   o  Populate an ACL with an assigned IPv6 address if the
network
      device in which the relay agent is instantiated
implements a
      security policy limiting IPv6 forwarding to devices
that have
      obtained an address through DHCP
   o  Inject routing information into a routing
infrastructure about a
      delegated prefix on behalf of a requesting router


I agree the DHCPv4 CSR is not expected to fill this purpose,
and no such examples are given, and no one should be
encouraged
to use the DHCPv4 CSR for this purpose.

I suspect all the (unfortuante, IMO) reasons everyone has
for the
DHCPv6 RAAN are just as applicable to DHCPv4.


> associated networking equipment. But, there are
problems
> with this when the client and relay reside on the same
> device which I will bring up in a separate message.   

OK.

> There are good reasons to avoid using a routing
protocol
> in the environment I am concerned with.

That's fair enough.

> If there is a
> stable aggregation point (or points) inside an
operator's
> network and many MNs moving about frequently between
ARs,
> we want to avoid injecting MN-specific routes into the
> IGP so that routing churn and IGP convergence latency
is
> avoided. We can do that if we can confine per-MN
routing
> updates to just the aggregation points and as
side-effect
> of the DHCP Solicit/Confirm/Renew/Rebind/etc
procedures.

Please forgive me for speaking as if my own experiences are
the
measure of the 'only right way' to operate IP networks, but
in
every network I've operated in the past, any architecture
that
involved something that looked suspiciously like a routing
protocol - but wasn't - and especially those that looked
suspiciously like maintaining a set of static routes via
contrived
dynamic means - was a PITA to debug and maintain.  An
operational
nightmare.

So perhaps what I'm trying to say is that I wish you luck,
but
I am skeptical that you will find it.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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

David,

Thanks for this; just as follow-up:

- I'll agree that a DHCPv4 RAAN option would probably be
  more suitable than a DHCPv6 CSR option. (But, the nice
  thing about DHCPv4 CSR and DHCPv6 RAAN is that they are
  both already documented.) With this input, plus the
"nays"
  I heard at the wg meeting, I'm not going to advocate
  further for any name changes.

- I said I was going to talk about client/relay interaction
  issues in a separate e-mail, but I'm not ready to send
  details on that yet; maybe later. In short, we would like
  to have a way for the co-located client and relay to talk
  to each other via a loopback interface. It appears to work
  fine for DHCPv6, but not so obvious how to make it work
  for DHCPv4 - any ideas?

- About dynamically managing (static) routes, yes that is
  what is being proposed. We need a reliable means for
  getting routing information propagated to the network
  equipment, and DHCP client assures reliability. We also
  need a means for detecting out-of-order delivery, and
  the SRSN option gives us that. (Admittedly, we still
  need something to fit that bill for DHCPv4).

  One way to look at it is that we are overloading DHCP
  to also act as a routing protocol, and maybe that's a
  fair assessment. Another way to look at it is that we
  are reusing widely-deployed mechanisms as a solution
  for the NETLMM problem space, which is the same argument
  successfully made by the Proxy Mobile IP (PMIP) advocates
  who had the largest show-of-hands in the NETLMM consensus
  call. (Although I'm not so sure the
"widely-depoyed"
  branding fits MIP as well as it does DHCP?)

Fred
fred.l.templinboeing.com 
     

-----Original Message-----
From: David W. Hankins [mailtoavid_Han
kinsisc.org] 
Sent: Tuesday, November 14, 2006 11:58 AM
To: dhcwgietf.org
Subject: Re: [dhcwg] dhc WG meeting summay

On Mon, Nov 13, 2006 at 04:03:49PM -0800, Templin, Fred L
wrote:
> Right, but the ARs also configure DHCP clients that
speak
> to the server on behalf of MNs that have recently
departed
> and/or MNs that do not use DHCP themselves.

That's right, you had relays that had colocated clients.  I
can see how this would create some confusion.

But I still think you're after a DHCPv4 RAAN, and have in
your
contrived situation determined to use the CSR for this
purpose.

That is, I think everyone who isn't colocating relays with
their
clients will have the opposite naming problem.

> the options. It seems safe to call them "static
routes" because
> no routing protocol is involved. It also seems safe to
call

That's not true.  The DHCPv6 RAAN draft explicitly states,
in section 3, 'Option Semantics':

   Examples of use:

   o  Populate an ACL with an assigned IPv6 address if the
network
      device in which the relay agent is instantiated
implements a
      security policy limiting IPv6 forwarding to devices
that have
      obtained an address through DHCP
   o  Inject routing information into a routing
infrastructure about a
      delegated prefix on behalf of a requesting router


I agree the DHCPv4 CSR is not expected to fill this purpose,
and no such examples are given, and no one should be
encouraged
to use the DHCPv4 CSR for this purpose.

I suspect all the (unfortuante, IMO) reasons everyone has
for the
DHCPv6 RAAN are just as applicable to DHCPv4.


> associated networking equipment. But, there are
problems
> with this when the client and relay reside on the same
> device which I will bring up in a separate message.   

OK.

> There are good reasons to avoid using a routing
protocol
> in the environment I am concerned with.

That's fair enough.

> If there is a
> stable aggregation point (or points) inside an
operator's
> network and many MNs moving about frequently between
ARs,
> we want to avoid injecting MN-specific routes into the
> IGP so that routing churn and IGP convergence latency
is
> avoided. We can do that if we can confine per-MN
routing
> updates to just the aggregation points and as
side-effect
> of the DHCP Solicit/Confirm/Renew/Rebind/etc
procedures.

Please forgive me for speaking as if my own experiences are
the
measure of the 'only right way' to operate IP networks, but
in
every network I've operated in the past, any architecture
that
involved something that looked suspiciously like a routing
protocol - but wasn't - and especially those that looked
suspiciously like maintaining a set of static routes via
contrived
dynamic means - was a PITA to debug and maintain.  An
operational
nightmare.

So perhaps what I'm trying to say is that I wish you luck,
but
I am skeptical that you will find it.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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

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

On Tue, Nov 14, 2006 at 03:01:41PM -0800, Templin, Fred L
wrote:
> Thanks for this; just as follow-up:

I agree with your summary, we're seeing eye to eye.

> - I said I was going to talk about client/relay
interaction
>   issues in a separate e-mail, but I'm not ready to
send
>   details on that yet; maybe later. In short, we would
like
>   to have a way for the co-located client and relay to
talk
>   to each other via a loopback interface. It appears to
work
>   fine for DHCPv6, but not so obvious how to make it
work
>   for DHCPv4 - any ideas?

Yeah, the idea of 'broadcast' is a bit odd on loopback
interfaces,
and critical to rfc2131.  I know our software throws
loopbacks out,
as it has to do weird things with BPF in order to transmit
rfc2131
compliant packets, and it doesn't make a lot of sense
usually to
try and address a loopback interface.

You may need to edge out a dummy interface rather than using
loopback aliases?  I don't know if that'll really help, I've
never tried it, and I'm not sure what software you're using.

If your relay doesn't have an MN-facing address until after
the
client has completed, you should be able to use the upstream
address as giaddr, and fill out an RFC3527 link selection
sub-option
with the MN-facing network (but this demands prescience of
the
MN-facing network's address).


Anyway, I think sufficiently molested software should be
able to
make this work.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Hi David,

Nothing to add for now, other than that your time and
careful consideration have been very valuable to us.

Now off to see if we can tame these client/relay
interactions...

Thanks - Fred
fred.l.templinboeing.com 

-----Original Message-----
From: David W. Hankins [mailtoavid_Han
kinsisc.org] 
Sent: Wednesday, November 15, 2006 11:21 AM
To: dhcwgietf.org
Subject: Re: [dhcwg] dhc WG meeting summay

On Tue, Nov 14, 2006 at 03:01:41PM -0800, Templin, Fred L
wrote:
> Thanks for this; just as follow-up:

I agree with your summary, we're seeing eye to eye.

> - I said I was going to talk about client/relay
interaction
>   issues in a separate e-mail, but I'm not ready to
send
>   details on that yet; maybe later. In short, we would
like
>   to have a way for the co-located client and relay to
talk
>   to each other via a loopback interface. It appears to
work
>   fine for DHCPv6, but not so obvious how to make it
work
>   for DHCPv4 - any ideas?

Yeah, the idea of 'broadcast' is a bit odd on loopback
interfaces,
and critical to rfc2131.  I know our software throws
loopbacks out,
as it has to do weird things with BPF in order to transmit
rfc2131
compliant packets, and it doesn't make a lot of sense
usually to
try and address a loopback interface.

You may need to edge out a dummy interface rather than using
loopback aliases?  I don't know if that'll really help, I've
never tried it, and I'm not sure what software you're using.

If your relay doesn't have an MN-facing address until after
the
client has completed, you should be able to use the upstream
address as giaddr, and fill out an RFC3527 link selection
sub-option
with the MN-facing network (but this demands prescience of
the
MN-facing network's address).


Anyway, I think sufficiently molested software should be
able to
make this work.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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

"Templin, Fred L" <Fred.L.Templinboeing.com> writes:

> There was a proposal at the meeting to rename the
> Relay Agent Assignment Notification (RAAN) option
> as the Classless Static Route (CSR) option for
> DHCPv6 (i.e., the DHCPv6-equivalnet of RFC3442),
> and it was suggested to take the discussion to
> the list. Reasons to rename the option include:

Without having read the draft, I have to state that my
default
starting point is that we do not want to do the above. We
have (so
far) intentionally _NOT_ defined a CSR option for DHCPv6.
That is what
RAs are for. The main argument against defining a CSR option
for IPv6
is that we already have a fine way of doing host routing,
namely, via
the RA mechanism. No one expects networks with routers to be
deployed
that do not support RAs. Thus, having multiple ways of doing
routing
just increases complexity and has no obvious benefits.

Let's please not go here.

Thomas

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

I have a slightly different feeling regarding a CSR for
IPv6. From my
point of view it is more straight forward to have a DHCPv6
option
equivalent to Option 121 for IPv4 when I want to do DHCPv6
PD and want
so signal a dedicated additional Route (that is bound to
that prefix)to
the Requesting DHCPv6 Router.
Or is there another solution to this problem, that I'm not
aware off?

Tnx and best regards
	Olaf

> -----Ursprungliche Nachricht-----
> Von: Thomas Narten [mailto:nartenus.ibm.com]
> Gesendet: Donnerstag, 16. November 2006 14:59
> An: Templin, Fred L
> Cc: dhcwg; Stig Venaas; Ralph Droms
> Betreff: draft-templin-autoconf-netlmm-dhcp [was: Re:
[dhcwg] dhc WG
> meeting summay ]
> 
> 
> "Templin, Fred L" <Fred.L.Templinboeing.com> writes:
> 
> > There was a proposal at the meeting to rename the
> > Relay Agent Assignment Notification (RAAN) option
> > as the Classless Static Route (CSR) option for
> > DHCPv6 (i.e., the DHCPv6-equivalnet of RFC3442),
> > and it was suggested to take the discussion to
> > the list. Reasons to rename the option include:
> 
> Without having read the draft, I have to state that my
default
> starting point is that we do not want to do the above.
We have (so
> far) intentionally _NOT_ defined a CSR option for
DHCPv6. That is what
> RAs are for. The main argument against defining a CSR
option for IPv6
> is that we already have a fine way of doing host
routing, namely, via
> the RA mechanism. No one expects networks with routers
to be deployed
> that do not support RAs. Thus, having multiple ways of
doing routing
> just increases complexity and has no obvious benefits.
> 
> Let's please not go here.
> 
> Thomas
> 
> _______________________________________________
> dhcwg mailing list
> dhcwgietf.org
> https://
www1.ietf.org/mailman/listinfo/dhcwg
> 

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

Hi Thomas, 

>> There was a proposal at the meeting to rename the
>> Relay Agent Assignment Notification (RAAN) option
>> as the Classless Static Route (CSR) option for
>> DHCPv6 (i.e., the DHCPv6-equivalnet of RFC3442),
>> and it was suggested to take the discussion to
>> the list. Reasons to rename the option include:
>
> Without having read the draft, I have to state that my
default
> starting point is that we do not want to do the above.
We have (so
> far) intentionally _NOT_ defined a CSR option for
DHCPv6.

We already had this discussion, and agreed that CSR for
DHCPv6 was not the right fit for our use case. There is
already a DHCPv6 RAAN option that fits the bill for what
we need.

> That is what
> RAs are for. The main argument against defining a CSR
option for IPv6
> is that we already have a fine way of doing host
routing, namely, via
> the RA mechanism. No one expects networks with routers
to be deployed
> that do not support RAs. Thus, having multiple ways of
doing routing
> just increases complexity and has no obvious benefits.

I'm not sure how RAs fit into this discussion, and it
would probably be most useful if you were to read the
draft. Routers advertising prefixes to hosts on attached
links is not the use case under consideration.

> Let's please not go here.

We already talked about it here on the list, came to
conclusions, and moved on.

Thanks - Fred
fred.l.templinboeing.com

Thomas

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