[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DHCP auth in unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt]

Hi Ralph,

Ralph Droms wrote:

4.1.2 Explicit prefix delegation

   Several networks have already started using an explicit prefix
   delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the
   gateway uses a DHCP request to obtain a prefix from a DHCP server
   managed by the ISP. The DHCP server identifies the gateway, for
   example, through identification information provided by the gateway
   in the DHCP request message or by the port or circuit through which
   the DHCP request message is received.  The server can implement
   prefix delegation policies based on the identity of the requesting
   gateway.  According to the recommendations in RFCxxxx the ISP
   assigns a /48 to the customer. The gateway then automatically
   assign /64s out of this /48 to its internal links.

(Editorial notes:
* I don't think the acronym "ISP" is defined anywhere in the document
* There doesn't seem to be a citation of RFC 3315 anywhere in the document
* There should be citations of RFC 2131 and RFC 2132 for DHCPv4)

   Security issues associated with DHCP and prefix delegation are
   addressed in the "Security Considerations" section of RFC 3315
   and RFC 3633, respectively.



No problem from my end with these suggestions; I believe RFC3177
may be the one you were looking for where you say: "RFCxxxx"?

4.1.3 Recommendation

   The ND proxy and DHCP methods appear to have different domains of
   application. ND proxy is a simple method that corresponds well to
   "informal sharing" of a link, while explicit delegation provides
   strong administrative control. The ND proxy mechanism has not yet
   been accepted as an Internet Standard and the interaction
   between neighbor discovery and ND proxy needs to be specified.



The thing that causes me to scratch my head and wonder is whenever I see
ND proxy and DHCP presented as competing (rather than complimentary)
functions.

I can see how a node that boots up in administrative domain A
will need to obtain autoconfiguration info; possibly to include prefix
delegtions from DHCPv6, etc. (After all, the node may very well have
an entourage of associated hosts for which it needs to provide packet
forwarding, address configuration, and possibly other services.) Then,
the collection of all such nodes and their associated hosts within
administrative domain A would form an arrangement of logical IPv6
subnets, and we have the delegated L3 prefix information to steer
intra-domain communications.

But, to enable peer-to-peer communications between a node within
administrative domain A and a remote node in administrative
domain B, I see the value of NDProxy. Put in loose english terms, I
think it makes sense to do NDProxy from a path that originates within
administrative domain A up to the edge of administrative domain B,
then use the delegated L3 prefix information within administrative
domain B to steer the remainder of the path to the final destination.

There seems to be elements of both routing and bridging mixed up
in this. But, I think it's more from a: "both/and" and not: "either/or"
perspective. In other words, I think this notion of a "brouter" or
"Rbridge" could be a good fit for your DHCPv6 prefix delegation
clients in this scenario.

Fred
ftemplin@iprg.nokia.com