[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip6] Re: RFC2136 and IP address ownership
[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
hi,
Olaf M. Kolkman wrote:
First an aside, "IP-ownership" is tricky terminology. The DHCP
community uses the term "lease" which, IMHO, better reflects that an IP
assignment is not for infinity.
In general the DNS allows maintenance of certain zones to be delegated
for technical managerial responsibility (which name servers serve the
zone, reflected in the NS RR set) as well as the responsibility for the
zones content (reflected through the SOA RR).
The "content manager" is responsible for the content of the zone and
will therefore need to grant certain parties the authority to update
the (reverse) DNS.
RFC2136 provides a hook for a client that has been granted authority to
update content to actually add, delete and modify using the DNS
protocol. RFC2136 uses "Primary Master" to describe which of the name
servers can be used for content management. (reflected to the MNAME in
the SOA). The authentication mechanisms used in this context are TSIG
and SIG0 but the authorization is still a local policy, managed outside
protocol. For one popular implementation the authorization is done
through configuration files.
It is completely local policy to which client this authority granted.
So to answer the question:
Isnt a client registering some other nodes IP address as its own
via RFC2136 an issue? RFC2136 does not seem to care about this IP
address ownership issue. Was this ever considered?
Indeed, RFC2136 is completely ambivalent about the zone content and
assumes that the authorization of who is allowed to update a certain
zone is done "elsewhere".
Skimming the MIP6 draft I see a lot of parties involved; I have not
read the drafts in enough detail to give sound input. Let me know if
that is needed at this time.
I can briefly describe whats in the draft. what we have done so
far is to let the home agent do the update (both direct and
reverse tree) instead of the mobile node. this assumes the home
agent is more trusted than the mobile node.
the home agent knows both the FQDN of the mobile node (through
IKEv2 authentication) and the home address of the mobile node
(since it is involved in the home address bootstrapping).
the mobile node is still in control because the home agent does
not do the update until the mobile node indicates this in the
binding update.
we just got around addressing the address ownership problem. :)
Vijay
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>