[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