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

Re: [dhcwg] about mip6-hiopt I-D



 In your previous mail you wrote:

   > I have still a concern about draft-ietf-mip6-hiopt-11.txt (I reviewed
   > for the gen-art the version 10) but I'd like to know if someone
   > shares my opinion.
   > My concernis the MIP6 Relay Agent Option (section 3.2 page 10) which
   > carries a part of replies from the relay to servers. IMHO this is
   > not the right way to do this:
   >  - if the local network has enough information so it could simply
   >   answer (a request can be about or partially about local stuff so
   >   ther should be a local DHCPv6 server).
   >  - if the local network has not enough information requests should be
   >   simply forwarded to a remote DHCPv6 server.
   >  - if the local network has the information but needs an AAA decision
   >   which can be done only at the remote network, requests should be
   >   forwarded to the remote network with a remote-id or subscriber-id
   >   carrying identification and AAA stuff about the client.
   > So in fact I can't see where Mobile IPv6 is special in this case and
   > why the standard way could not be used...
   
   The scheme you described above is the "standard"? Is it documented anywhere?

=> it is the way relays (including DHCPv4 relays even DHCPv6 relays are
more flexible) are used so documentation is in RFC 3315, 4580 and 4649
(and about policy stuff in DOCSIS specs).

   I agree it could be done that way, but I perceived this as an optimization
   when I first saw your comment.
   
=> if the optimization is to cache the infos locally the idea is not mine
but the I-D (and bootstrapping scenario) one. My point is to put the
infos from relay to server way doesn't make sense.

Thanks

Francis.Dupont at fdupont.fr
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg