Subject: [dhcwg] Re: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt

From: Bernard Aboba <[email-masked]> (by way of Ralph Droms <[email-masked]>)
Date: Thu, 15 May 2003 11:22:08 -0400

>    In this example an AAA server is configured with a prefix assigned to
>    the customer at the time of subscription to the ISP service. The

Who is the "customer" in this case? Is it the subscribing PC? The
requesting router?

>    prefix delegation process begins when the requesting router requests
>    configuration information through DHCP.  The DHCP messages from the
>    requesting router are received by the delegating router in the
>    aggregation device.  When the delegating router receives the request,
>    it consults the AAA server to authenticate and authorise the
>    requesting router.

Are we saying that a DHCP request triggers a link authentication exchange?
Typically it's the other way around because links are not enabled
until link authentication completes, so it is not possible to have a DHCP
exchange over a link that is not yet enabled.

Also, I am not sure what "consults" means here. Is the delegating router
just forwarding packets? Or is it acting as an authenticator of some kind
with the requesting router acting as the authenticating peer?

>    The AAA server returns the subscriber's
>    prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162
>    [7], and the delegating router returns them to the requesting router.

How does the delegating router return them? Via DHCP? Via forwarding the
AAA response to the requesting router? If the later, then we're assuming
that the individual PCs authenticate to the delegating router?

>    The requesting router subnets the delegated prefix and assigns the
>    longer prefixes to links in the subscriber's network.  In a typical
>    scenario based on the network shown in Figure 1, the requesting
>    router subnets a single delegated /48 prefix into /64 prefixes and
>    assigns one /64 prefix to each of the links in the subscriber
>    network.
>
>    The prefix delegation options can be used in conjunction with other
>    DHCP options carrying other configuration information to the
>    requesting router.  The requesting router may, in turn, then provide
>    DHCP service to hosts attached to the internal network.  For example,
>    the requesting router may obtain the addresses of DNS and NTP servers
>    from the ISP delegating router, and then pass that configuration
>    information on to the subscriber hosts through a DHCP server in the
>    requesting router.

Overall, it seems reasonable to me for the requesting router to do link
authentication with an upstream device (which may or may not be a router;
it could be a bridge). The AAA server can return IPv6 prefixes to the
authenticator, who could plumb them. Note that depending on the
authentication protocol, there may not be a way for the requesting router
to know that the prefixes have been assigned. For example, IEEE 802.1X
does not support any IP-layer configuration (unlike PPP IPv6CP).

So the Requesting router (or PCs which attack to it) may need a DHCP
exchange as well. That occurs *after* link authentication, and
needs to return answers consistent with the AAA prefix assignment. This
can be accomplished, for example, by having the device that received the
AAA prefix assignment act as a DHCP server, subnetting the delegated
prefix.

In this case, I'm not clear that the requesting router is acting as an
authenticator, rather than as a peer. Or is it the one that is sending the
AAA requests and getting AAA responses with IPv6 prefix info? If so, then
it could do the delegation -- but I'm sure what the delegating router
does.

I guess I'm confused, huh?

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 15 May 2003 17:12:38 +0100

Bernhard,

> Who is the "customer" in this case? Is it the subscribing PC? The

"customer" is the whole site behind the RR.

> Are we saying that a DHCP request triggers a link authentication exchange?

no.

> exchange over a link that is not yet enabled.

correct.

> with the requesting router acting as the authenticating peer?

yes.

> that the individual PCs authenticate to the delegating router?

DHCP PD. AAA (or whatever protocol) is used in the back end. devices
behind the RR is not involved in DHCP PD at all.

> I guess I'm confused, huh?

obviously. :-)

the model for PD where AAA is involved is as follows:

the link between RR and DR uses link authentication. AAA is used
between the DR and the ISPs provisioning system.

DHCP PD _can_ reuse the authorisation data acquired during the link
authentication phase to provide DHCP prefix delegation. PD is run between
the DR and RR. no device behind the RR is involved.

the RR is not involved in AAA, the only way it can receive any
prefixes is through DHCP PD.

the link authentication protocol used does not matter as such (as long
as the DR is involved in it) as we do not depend on any network layer
parameters being negotiated.

cheers,
Ole

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 09:40:37 -0700 (PDT)

> between the DR and the ISPs provisioning system.

OK.  Having a diagram showing that would be helpful.

> authentication phase to provide DHCP prefix delegation.

Only the DR has the AAA authorization data since it is the one that
receives the AAA response, not the RR.

> PD is run between

OK. I assume that the DR responds based on the AAA assigned prefix (say
/48)? The RR obtains this prefix from the DR, then subnets it for use with
its "customers", right?

> prefixes is through DHCP PD.

Right.

> parameters being negotiated.

Great. This makes sense -- but I think you need some diagrams showing what
protocols are spoken between what parties to make all this clear.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg