Subject: Re: IPv6 and Dynamic DNS

From: Robert Elz <[email-masked]>
Date: Tue, 03 Aug 1999 02:54:50 +1000

Date:        Mon, 02 Aug 1999 12:19:30 -0400
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | IPv6 will also support DHCPv6 as an alternative to using the router for
  | your prefixes for addr conf too.

OK, I should have been clearer, obviously if DHCPv6 is being used, then
the DHCP server can do things for v6 exactly as for v4.   I was concerned
with the case where DHCPv6 isn't being used.

  | Not entirely correct either.  The node can do the update or the DHCPv6
  | server for the node.

If we assume there is no DHCPv6 server (which for example I don't believe
there was in Oslo) then it has to be the node, right?   But from where is
the node going to get the authority to do this?   Typically it will have
no knowledge at all of the net where it is being connected, which also
implies that it can't know what credentials it can usefully supply to get
permission to update the zone file.

  | If the issue is authority then that is TSIG initially and then DNSSEC.
  | Then its a matter of getting the key.

Yes, exactly.   That small matter.   Does this imply that if I come visit
you one day, you're going to hand over the key to your zone file to my
laptop?

  | For BIND folks this is in the 8.2
  | release and works with Dynamic Updates to DNS implementation APIs.

Right now, I'm not concerned with the software to make this work, I know
that's on the way.   It is how it is supposed to be all glued together so
it can work in practice.

  | With dynamic updates to DNS its just a PTR record for IPv6 like IPv4
  | under the IP6.INT domain.

Sure, I understand this much Jim....

  | Maybe I am missing your issue as I don't see it?

The point is where my node gets the authority to do the update (assuming
that DHCPv6 isn't being used, if it was the server would just do the
update, as for v4, that's easy to arrange to work).   But we haven't
moved to mandating DCHPv6 yet have we, autoconfig is still an option, right?
So assuming that autoconfig is what my node does (and is what I do in fact
do as I have a router which is sending out the RAs I need for this), where
does my node manage to find the key to update some random network it happens
to be connected to today?

It can easily update the forward zone, as its domain name doesn't change,
no matter where it connects, so configuring it with a key to permit that
update is easy.   But for the reverse zone file this doesn't look like quite
such an easy problem (and it certainly can't be swept under the floor by
saying "you should use DHCPv6 if you need to do that").

kre

---

From: Jim Bound <[email-masked]>
Date: Mon, 02 Aug 1999 13:43:39 -0400

>you one day, you're going to hand over the key to your zone file to my

Well right now thats kind of how it must work.  There is no key exchange
that I am aware of we have agreed to for TSIG.  For DNSSEC I believe we
assume a PKI but don't quote me on that as I await that too.  But
sneaker net is in fact the mechanism.

>that's on the way.   It is how it is supposed to be all glued together so

Well its working in practice now in a sense with the DHCPv4 servers but
as you say at least there is some "implied" authorziation btw the DHCPv4
server and the client.  But not necessarily any real authority btw the
DHCPv4 server and the DNS master of the zone.  So I think the inherent
problem is exchange of keys for DNSSEC.  If we know what the answer is
for that generically we know the answer for IPv6 and IPv4 IMO.  For TSIG
we will use what we can for our customers.  

>to be connected to today?

1.  I would like to point out that because a DHCPv4ORv6 does the update
does not mean its secure in DNS.  

2.  There is an M bit in stateless addr conf which right now the only
solution being proposed is DHCPv6.  

3.  Right now in addrconf in the case of BIND there are mechanisms to
build the key but we are just testing this now in 8.2.

4.  As far as the IETF ruleset for authentication I am hoping thats in
DNSSEC but I can't find it now.  

5.  It appears us vendors will deploy per #3 above and not wait for the
issues with #4.

So maybe the result of your mail is we need to define key exchange
mechanisms as a standard for dyn upds to DNS?

If so then I think its irrelevant if the update is done by the client or
the server?  Both need the same security measures.

Also there is nothing to prevent an IPv4 DHC client to upate DNS without
even going to the DHCPv4 server.  We build rfc2136 so there would be no
hard dependency on an intermediate (e.g. DHCP, SLP, etc) server for dynamic 
updates to dns.

>saying "you should use DHCPv6 if you need to do that").

I agree it should not be swept under the rug either nor did I suggest
that in mail Sir...........

I would argue there is no difference between either zone file once you have
the credentials at the client (whether that be a dhcp server or a node
that is just a client) you have the proper permission to speak with the
server and the server knows the different btw name->address map updates
and address->name updates.  

/jim

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Aug 1999 06:02:09 +1000

Date:        Mon, 02 Aug 1999 13:43:39 -0400
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well right now thats kind of how it must work.

Yes, and that's what I was asking about, as in general, that's not
a satisfactory method.  Or not for the kind of dynamic information
that is involved here (getting manually configured with a key is
fine for the forward zone, as the name changes rarely, and this is
easily possible - having to do the same for the address is beyond
reasonable as a burden).

  | Well its working in practice now in a sense with the DHCPv4 servers but
  | as you say at least there is some "implied" authorziation btw the DHCPv4
  | server and the client.  But not necessarily any real authority btw the
  | DHCPv4 server and the DNS master of the zone.

No, not necessarily, but it can usually be worked out, and this is the
assumption that has generally been made, and which I think underpins the
relevant DHCP options.   That is, while there isn't necessarily a
relationship between the admin of the DHCP server (who is allocating the
addresses to various objects on the net) and the zone file maintainer
for the in-addr.arpa (or ip6.int) zone file, who is publishing the
assigned addresses, in most cases these two entities are likely to work
closely together, and have arranged the mechanisms to do so - and if that
involves allowing the DHCP server to dynamically update the zone file,
then that will usually happen.

For IPv4 this (or manually having an adress assigned, and having the
zone file manually updated at the same time usually) are the only options.

For IPv6 we have this alternate, and much simpler, mechanism.   But it isn't
going to be a viable mechanism unless we also have a way to get the DNS info
updated - and right now I'm seeing nothing (not even any attempt) to find that
method.

Note that this really has nothing whatever to do with key exchange per se, 
though that may become a component.  It is a question of authorisation, and
where that comes from.  Keys are just a method to demonstrate that
authorisation exists, they don't provide it in the first place, and it is
that first step that I don't see here.

  | 1.  I would like to point out that because a DHCPv4ORv6 does the update
  | does not mean its secure in DNS.

No, and this has nothing whatever do do with the question.

  | 2.  There is an M bit in stateless addr conf which right now the only
  | solution being proposed is DHCPv6.

Yes, I know, and if that method (any such method) is in use, then the
problem I forsee doesn't arise.  All the others you're alluding to are
still there, but those are at least known, and being worked upon, so I'm
not so worried about them.

  | 3.  Right now in addrconf in the case of BIND there are mechanisms to
  | build the key but we are just testing this now in 8.2.

This has nothing to do with the problem.

  | 4.  As far as the IETF ruleset for authentication I am hoping thats in
  | DNSSEC but I can't find it now.

I'm not sure what this means, but I suspect it is also missing the point.

  | 5.  It appears us vendors will deploy per #3 above and not wait for the
  | issues with #4.

Fine, but I still see nothing at all which addresses the problem here.

  | So maybe the result of your mail is we need to define key exchange
  | mechanisms as a standard for dyn upds to DNS?

No, nothing like that at all.

  | If so then I think its irrelevant if the update is done by the client or
  | the server?  Both need the same security measures.

Yes, they do.   The question is still how and where is the authorisation
to use whatever security measures exist is granted.   If a server is doing
the update, this is easy, as the existence of the server is known, it can
be allowed to use (via whatever mechanisms are appropriate) whatever it
needs to get its job done.    Since clients just appear, and the IPv6
autoconfig is supposed to let them just start running (assuming the net admin
allows that, and remember I am assuming that here) I don't see how they're
going to be authorised to do anything at all (related to the address).

So we have no server (dhcp type server - this is the assumption) and
unauthorised clients (not clients without a key - unauthorised clients).
But we still have the ip6.int zone file to get updated, somehow.

  | Also there is nothing to prevent an IPv4 DHC client to upate DNS without
  | even going to the DHCPv4 server.

No, of course not, assuming the authorisation exists.   I believe that the
general assumption is that it won't normally do that for the in-addr.arpa,
since it isn't expected to have any a priori knowledge of what address
it is going to be given, it also can't be expected to have any authorisation
to make the update - however circumstances can be odd, and in some
circumstances the client may be able to perform the update.  The same would
be true for IPv6 in similar circumstances.   But this uninteresting case
does nothing to solve the general problem.   We get no closer to solve the
problem by pointing out the cases in which the problem doesn't exist, unless
you're also able to show that those cases cover all the relevant cases,
and here, I don't believe that is possible.

  | I would argue there is no difference between either zone file once you have
  | the credentials at the client

Of course.   The question is where those credentials came from.   I thought
I had made that clear in the last mesage, if not in the first one.   Perhaps
I have this time?   And once again, this has nothing to do with any kind of
key distribution protocol - any of those must still require some kind of
authentication before blindly handing out any key that some random client
chooses to ask for.   Its at that level that the problem arises here.

kre

---

From: John Gilmore <[email-masked]>
Date: Mon, 02 Aug 1999 16:29:27 -0700

> For IPv6 we have this alternate, and much simpler, mechanism.  But
> it isn't going to be a viable mechanism unless we also have a way to
> get the DNS info updated - and right now I'm seeing nothing (not
> even any attempt) to find that method.

I question the assertion that DNS info must be updated when an IPv6 node
gets on a local Ethernet.

If you're at home, your DNS forward and reverse info will be correct.

If you're off visiting somewhere else, then it's not clear that you
always want to repoint the forward entry, and if you aren't making a
good forward entry then there's nothing to put into the reverse entry.

You may well be right that IF you want to make a reverse entry,
there's no good mechanism for it, but that's a separate issue than
"dynamic IPv6 address assignment will fail unless we solve this
critical issue".

(In fact, if a DNS server receives a dynamic update for a reverse
entry, and it can verify that the pointed-to forward entry matches,
and the source address of the reverse entry is the address being
updated, it could consider making the update.  What can we do to improve
this model so it need not trust the source address of the update packet?)

	John

---

From: Jim Bound <[email-masked]>
Date: Mon, 02 Aug 1999 23:41:23 -0400

Your asking then where do the credentials come from to update the
address->name mapping?

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 02 Aug 1999 23:49:53 -0400

>this model so it need not trust the source address of the update packet?)

This is a question I can understand.  Exactly.  We have ddns working for
both AAAA and PTR records from IPv6 addrconf.  The issue is for my
customers how is that made to be secure.  What you ask is exactly what
we need to solve.

/jim

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 04 Aug 1999 17:08:09 -0400

How is the problem of a DNS server telling if an update to the inverse
zone is authorized different from a DHCP server telling if a request
for an address is authorized?  Don't DHCP servers generally give out
addresses to anyone who asks so a machine that can spoof Ether
addresses can exhaust it?  If so, why wouldn't you expect the same
machine to be able to fill the inverse zone with crap?  If there is a
solution to client-to-DHCP autentication, presumably it would work for
client-to-inverse-zone-DNS-server.

Donald

PS: I think having the inverse tree is very useful.  I also think it
is reasonable to verify the results of the inverse look up against the
forward look up in many circumstances.  For example, if the forward
tree was secured using DNSSEC but the inverse tree were not, the
forward verification would actually give you a lot of confidence.

From:  Jim Bound <[email-masked]>
X-Authentication-Warning:  opsmail.internic.net: majordom set sender to owner-namedro
[email-masked] using -f
Message-Id:  <[email-masked]>
To:  John Gilmore <[email-masked]>
cc:  Robert Elz <[email-masked]>, Jim Bound <[email-masked]>,
            [email-masked], [email-masked]
In-reply-to:  Your message of "Mon, 02 Aug 1999 16:29:27 PDT."
	                  <[email-masked]> 
Date:  Mon, 02 Aug 1999 23:49:53 -0400

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Aug 1999 00:36:03 +0200

=> I have in my TODO list the same kind of tools (ie. something which
updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery).
Of course we have the same problem and the current proposed solution
is to use TSIG, the future solution is to provide this service via DHCPv6.

Regards

[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Aug 1999 18:49:00 +1000

Date:        Fri, 06 Aug 1999 00:36:03 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => I have in my TODO list the same kind of tools (ie. something which
  | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery).

This one is interesting, and is the first real suggestion I have seen that
there might be a solution.

The question that James Cutler asked - whether we need bother with PTR
records at all is certainly a valid one.   Unfortunately, most of the
discussion that followed, which concentrated on what security exists
with PTR records was way off the point - totally irrelevant.

Francis - I'd very much appreciate a brief message on just how your
proposed tools might go about this task.   It doesn't seem to me that
it is going to be trivial, though I can see it might be possible.

kre

---

From: Peter Tattam <[email-masked]>
Date: Fri, 6 Aug 1999 21:15:28 +1000 (EST)

One other thought I have had is to use a totally synthesized system.  To
implement this would simply require some naming conventions.  We would use the
lower 64 bits of the address to form a token representing the host. An example
would be the best way to explain.

My host for example would be

0200-F8FF-FE20-7CF8.ip6.trumpet.net.  AAAA 3ffe:8000:1:::200:F8FF:FE20:7CF8

The PTR record would be

8.f.c.7.0.2.e.f.f.f.8.f.0.0.2.0.0.0.0.0.1.0.0.0.0.0.0.8.e.f.f.3.ip6.int. PTR
0200-F8FF-FE20-7CF8.ip6.trumpet.net.

I think my example is correct (please pardon any mistakes).

As long as the naming convention was adhered to, a quick verification can be
made for the validity of each type of entry.  The unsynthesised part is still
under the control of the DNS system.

All that's needed is that the DNS servers synthesize according to the rules.

This fits the stateless autoconfig model fairly well too.

It satisfies the requirement of one-one correspondence between the names, and
should correlate well with actual IP addresses.  An additional sanity check can
be made to prevent spoofing as the lower 64 bit components of each side should
always match.

The only configuration requirement that the DNS servers need is to know which
which site network (upper 64 bits) that is is allowed to synthesize.

Apologies if this has already been thought of, or is already in an I-D.

This could be implemented with binary labels as well, but would
require a fair bit more work than this current idea.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Peter Tattam <[email-masked]>
Date: Fri, 6 Aug 1999 21:15:28 +1000 (EST)

The PTR record would be

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 6 Aug 1999 19:45:10 +1000 (EST)

> it is going to be trivial, though I can see it might be possible.

I can see some considerable problems if the client initiates contact with the
DNS servers since typically ND & stateless config would probably be done at
kernel level.  Usually DNS related stuff happens at user level in my
experience.  Mixing the two might be a bit of a headache, but not impossible.

>From a general point of view,  I see two ways to approach the problem.

a) The host machine pushes the information into the DNS system.

b) The DNS system pulls the information from the host machines as needed.

There are different security implications for each approach.

I personally favour the second approach via a "who are you" style of query.

In my DNS server, I have a feature to automatically synthesize PTR records from
A and AAAA records. It works fine, and you can also add manual entries if you
want.

One *could* synthesize a DNS entry symbolically I guess.

The typical sequence of events would be.

1. Some host requests a PTR query of the DNS server.

2. DNS server does a "who are you" to Ipv6 address.  (Filtered of course by
site).

3. Machine can then reply a "real" name (manually configured) or "undefined".

4a. If "real" name, a verification has to be made for a duplicate name in the
DNS.  If there's a clash then change it to "undefined".

4b. If "undefined", the DNS server synthesizes a symbolic name to represent
that host. Format to be defined...

5. The DNS server then enters this name as a PTR record.  An AAAA record could
also be synthesized if the the PTR and AAAA records are on the same site.

Looking up an AAAA record is more complicated when AAAA & PTR are on different
DNS servers.

This could be done in several ways.

a) modifying DNS to allow an inverse query on the PTR record (impractical). The
AAAA server then queries it's known list of PTR servers for required
information.  You might as well have the AAAA & PTR servers integrated anyway
in this case as this would simply degenerate into a classic AAAA query on the
PTR server.

b) doing a multicast on the entire site for a FQDN.  This might not be very
popular at all.  There are problems when the SOA server is some distance from
the site network. 

c) having some kind of feedback from the PTR server to other AAAA servers. 
This would require the design of an out of band (from DNS point of view)
mechanism to convey the information. 

Another idea comes to mind, and that is each IPv6 stack act as a mini DNS
server configured with all the correct information relating to what addresses
are already configured.  However, one then has the problem of grafting the host
into the DNS tree.  This could potentially by done using some kind of mechanism
that allows immediate DNS children to be reliably sought.  I could do a whole
lot of hand waving here, but I think it would degenerate into a method very
similar to what I suggested earlier.

Finally, if a push solution is sought, then we would have to define a way for
the DNS tree to be updated.  My understanding is that the DNS tree is
effectively read only when queried through the resolver process.  I'm not
really up to speed on DNS research, and maybe there are extensions that allow
grafting to be done..  (recipe for major trouble if you ask me though :)

Just my random thoughts on the issue

Peter

---

From: Jim Bound <[email-masked]>
Date: Fri, 06 Aug 1999 15:53:53 -0400

>there might be a solution.

Hmmm.   already wrote the code to do this and it work and I said so in
my first response to your mail ????

This runs now on Compaq Tru64 UNIX.  If you have an Alpha you can pull
our v6 kit and test it at munnrai.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 06 Aug 1999 23:00:45 -0400

Peter,

>experience.  Mixing the two might be a bit of a headache, but not impossible.

ND and Addrconf it is true are processed as ICMP msgs at the network
layer (by design in IPv6) which is often referenced as the kernel. But
the "daemons" for managing and processing ND and Addrconf are done in
user space.  This is one of the reasons why we defined the Adv API
rfc2292, and is being reviewed for updates to fix things we found from
implementing it now by Erik Nordmark.  Basically ICMP filters are
processed via raw sockets and those parts in ND which identify Stateless
Addrconf are processed by a daemon.  Similar to the fact that most
routing is done by daemons too not in kernel space but in user space. 
So the update to DNS is from user space in this case.  But the addresses
are maintained in the kernel on the normal BSD like ifnet structure.
Also DHCPv6 will be forked, threaded, whatever because of what is told
to the Addrconf modules within the ND daemon to start a DHCPv6 client or
not and what it can and cannot do (see Addrconf spec).

/jim

---

From: Robert Elz <[email-masked]>
Date: Sat, 07 Aug 1999 20:41:12 +1000

Date:        Fri, 06 Aug 1999 15:53:53 -0400
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hmmm.   already wrote the code to do this and it work and I said so in
  | my first response to your mail ????

Maybe I misread Francis' message, but I thought he was saying something
different than your message suggested.   You said ...

	|| The node can do the update or the DHCPv6
	|| server for the node.

While I have no doubt that's true, it isn't the case that is of interest,
and it isn't what I thought that Francis was proposing.

That is, right now, I'm only interested in the case where there is no
DHCPv6 server (stateless autoconf) and the node has no authority to do
anything to the appropriate DNS server.   Hence, something else would
have to do the update, some other way.

Of course, I may have totally misunderstood Francis' idea, which is why I
asked for more details.

It's also possible that your code already does something which you didn't
explicitly say, or which I just missed (then, and again now).

  | This runs now on Compaq Tru64 UNIX.  If you have an Alpha you can pull
  | our v6 kit and test it at munnrai.

I do (munnari is an alpha, though it isn't going to start running any
experimental code).    I have run an earlier version of your code, it
worked fine, then the alphastation I was running it on got an updated
version of Dunix (this was before the Tru64 name appeared) and the
IPv6 stuff vanished...   I did look at getting an updated version, but
it seemed to want more red tape than I felt like indulging in, so I
didn't bother (for the earlier version it was just there, and I ftp'd
and installed it).   I haven't looked to see what the current procedure is
for a while though, so I guess I should go back to your web site and
have another look.

kre

---

From: Terry Lambert <[email-masked]>
Date: Sun, 08 Aug 1999 15:00:18 -0700

Robert Elz wrote:
>   Jim Bound wrote:
> While I have no doubt that's true, it isn't the case that
> is of interest, and it isn't what I thought that Francis
> was proposing.
> 
> That is, right now, I'm only interested in the case where
> there is no DHCPv6 server (stateless autoconf) and the node
> has no authority to do anything to the appropriate DNS
> server.   Hence, something else would have to do the update,
> some other way.

I totally agree.  The interesting case is stateless autoconf;
perhaps I'm not asking the question correctly, since it seems
to me that I should probably no more trust the host name in
the DHCP request than I would trust a reverse update not made
by proxy through the DHCP server.

Assumption:

	The visiting machine will get a forward record
	pointing to its configured address put into its
	_home_ DNS, somehow.  That is, the machine keeps
	its identity, regardless of where it obtains its
	network connectivity.

Question:

	How does the visiting machine get a reverse record
	_without human intervention_?

> Of course, I may have totally misunderstood Francis' idea,
> which is why I asked for more details.
> 
> It's also possible that your code already does something
> which you didn't explicitly say, or which I just missed
> (then, and again now).

If so, I missed it too.  From what I gather, if it did the
job, it could only be applied to close neighbors, which
shoots down discovering the intended name of a visiting
machine, since it's in a foreign DNS.

This is really, really painful for things like dial-on-demand
mail servers that need to send an ETRN.  I have a design that
works now without resorting to SMTP AUTH (or my own, CALLID)
extension for IPv4, but it relies on RADIUS accounting records,
which give poor disconnection notification.  I was hoping that
there would be something more elegant on the horizon.  8-(.

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 09 Aug 1999 09:40:38 -0500

> 	_without human intervention_?

I think we all agree that there's no Truly Secure way to do it.  So
we're trying to agree on a Pretty Good algorithm.  I suggest that the
update to the reverse zone involve a check that the subject address
isn't already allocated, a cross-check of the forward zone and a
challenge-reponse interaction with the subject address.

				Matt

---

From: Jim Bound <[email-masked]>
Date: Mon, 09 Aug 1999 09:17:30 -0400

Hi,

>and it isn't what I thought that Francis was proposing.

In my sentence above "node can do the update" I was implying you would
know I would do it based on an ND+addrconf msg giving me the address.
Anyway I have already implemented what Francis is speaking of and my
first sentence the referenced mail above was asking for us to test this
at UNH this Novemeber. Sorry for my assumptions in my mail maybe I could
have saved a lot of mail had I been more verbose.  Anyway what Francis
stated we will all do as IPv6 implementors one way or the other.  The
reason is that unlike IPv4 a customer can deploy IPv6 without DHCPv6
(its a choice).  When the node gets addresses in that case from
Stateless addrconf DNS will have to be updated by the node itself
without a server.

>have to do the update, some other way.

I would suggest if there is no DHCPv6 server and the node does not have
the authority to do anything to the DNS server then nothing is done as
there are only two ways this can happen:

  1.  the node itself has authority to update the DNS.
  2.  the node uses DHCPv6 to update the DNS and the DHCPv6
      server has that authority.

>Of course, I may have totally misunderstood Francis' idea, which is why I

I am not sure now???

>explicitly say, or which I just missed (then, and again now).

No I did not say explicitly;

ND sends Rtr Adv and sets the A bit for stateless.
ND also sends Prefixes that can be used for addrconf by nodes on
the link.

The ND daemon sees this set and will now take prefixes and form 
addresses (DAD and all req processing assumed for the EUI link-local
part).

The ND dameon takes the preifx and EUI per IPv6 over foo spec and forms
an IPv6 address.  Puts that into the NUD processing and puts that
address on the set of IPv6 Interface structures for the node in the
kernel.  Starts the necessary timers for the address to reach
deprecation state, and the next state etc..

So all the IPv6 processing is now done for the address to be usable.

Now the ND daemon takes that address and updates the AAAA and PTR
records per RFC 2136 dynamic updates to DNS using BIND as our
implementation.  Right now we do that without security.  Working now
with BIND 8.2 to use TSIG to verify that the node is infact able to
update the DNS.  So TSIG would be used to verify the node can do updates
to AAAA and PTR records (this is all transparent to the A6 record issues
as that change will be in libraries behind the ND app daemon in our
resolver when it happens).

>for a while though, so I guess I should go back to your web site and

Red tape sucks I agree.  We try to avoid it when possible. We have a
mail address you can send to get help and support on the web page if it
gets bogus doing anything with our kit.  We usually respond in less than
24 hours (one of us on the eng team will respond to).

Now once DHCPv6 exists (hopefully real soon too) we will have to have a
config switch to ask the user do you want DHCPv6 server to do your DNS
updates.  In IPv6 unlike IPv4 stateless and stateful can coexist and be
running simultaneously.

/jim

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 10 Aug 99 9:32:11 JST

Matt;

> we're trying to agree on a Pretty Good algorithm.

Silly agreement.

Stateless autoconfiguration has absolutely no security.

The only reasonable way to go is to abandon stateless autoconfiguration
except for an isolated small LAN.

Note that even dentists' offices need global connectivity with
reasonable security.

That something has interoperable implementations does not mean it
useful in the real world.

							Masataka Ohta

---

From: Tom Limoncelli <[email-masked]>
Date: Mon, 09 Aug 1999 18:39:28 -0400

I have a really dumb question about all this.

Consider this situation:

My laptop is tomslaptop.mycompany.com.

I visit SomeoneElse, Inc. and plug my laptop into their network and use
autoconf or DHCPv6 to get an address.

What should I expect as my FQDN?  Is it tomslaptop.someoneelse.com or
should I expect the right DNS updates to maintain my name as
tomslaptop.mycompany.com.

Note: I'm not asking about reverse lookups.  Depending on the answer to
the question above I have different questions about reverse lookups.

Thanks,

-tal

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 09 Aug 1999 17:48:33 -0400

> challenge-reponse interaction with the subject address.

How about taking advantage of the TTL=255 hack?  (i.e., any packet
recieved with a TTL=255 hasn't gone through a router, and thus, must
have originated from a directly-connected system?  this is already
used by the v6 neighbor discovery protocol).  

You then put a proxy connected to each wire which is set up to use
stateless autoconfig which is trusted to update the inverse-zone for
that wire...

					- Bill

---

From: [email-masked]
Date: Tue, 10 Aug 1999 04:04:45 -0700 (PDT)

> the question above I have different questions about reverse lookups.

	My working assumption is that you keep your FQDN and
	only the address mapping changes.

-- 
--bill

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 01:24:34 -0400

> I have a really dumb question about all this.

This is a smart question and we need more of them.

> autoconf or DHCPv6 to get an address.

Ah the real world.  This will be really happening. 

> tomslaptop.mycompany.com.

If your lap top supports dyn upds dns when you get addrconf address you
can provide a name to go with your new address within the zone the master
server resides in where your located.  So when send in your address 
7dde::1 you would also provide the name you want to use based on the
zone suffix in your DNS config.  So if your DNS suffix config is
SomeoneElse.com for who you are visiting you would send along
tomslaptop.SomeoneElse.com as your name for 7dde:1.  If the name is
taken you will get a dyn upd dns error code to your dyn upd dns
implementation on your laptop.  Or you could get your not authorized, or
the server is down...etc... see RFC 2136.

Now if you use DHCPv6 you can still request what you did above OR ask
the DHCPv6 server to provide you a name.  The same rules apply above to
the DHCPv6 server.  Or the DHCPv6 server could be configured to just
give you a FQDN with your new address when you get it.  That can't be
done with addrconf.  

/jim

---

From: Tom Limoncelli <[email-masked]>
Date: Tue, 10 Aug 1999 09:31:38 -0400

> the server is down...etc... see RFC 2136.

I see two situations, none of them good:

Situation 1:  I visit SomeoneElse.com and request that I remain
tomslaptop.mycompany.com and the request succeeds.  Now if I do anything
bad, the liability sticks with mycompany.com, which is good.  However,
when outsiders complain to [email-masked], SomeoneElse's sysadmins
will find it difficult to debug, since the domain name doesn't match
their own company.  ("If the attack is coming from *.mycompany.com, why
did you email [email-masked]?").  Or, complaints go to
[email-masked] and a reply comes back saying "Those bits are coming
from SomeoneElse.com even though the domain doesn't match that."  Much
confusion.  If the management at SomeoneElse.com is informed, they'd be
pretty angry to find that bits are leaving their internet connection with
some other company's name tagged on them.  On the other hand, they might
not like evil packets being tagged with their name on them.  [Note: when
I say "tagged with their name on them" I know that the FQDN isn't
included in each IP packet, I just mean that it can be traced back to
them.]

Situation 2:  I visit SomeoneElse.com and request that I be
tomslaptop.mycompany.com and the request fails.  I am instead assigned
topslaptop.SomeoneElse.com or even random-guest-7dd--1.SomeoneElse.com. 
Liabilities are traced back to the source company (this helps tracking
down the problem) but could make SomeoneElse.com look bad (result=unhappy
management).

Either way, we don't win.

Maybe I'm a control freak, but if Victoria Visitor plugged her laptop
into my network, I would possibly let her keep her hostname (shortname)
but she'd get my domain name, and if her MAC address wasn't registered
with my IT staff that domain would be
vvlaptop.guests-visiting.mycompany.com.  Heck, I won't permit dyndns
updates through my firewall (in either direction!) so I know that any
attempts by visitors will be thrwarted.

If I was running an ISP, maybe things would be different.  If every
airport had public LAN connected to a local ISP, then I would want to be
able to plug my laptop in at any airport and always get
tomslaptop.mycompany.com.

Sidenote: This sort of reminds me about the delemma of Automatic VLANs. 
Sure, I can now put any subnet in any office in my building, but do I
want to?  After a year of entropy I would find an unmanagable network. 
Technicians (who tend to be "trace the wire"-types, not "write a perl
script"-types) can't get their job done because every port of every
switch could be a very different subnet.

I don't have any answers, but I think the right questions are:
	Machines have a SHORTNAME+DOMAIN plus a PTR record.  Should the DOMAIN
match host's owner or the network's owner?  Or should it be the local
admin's choice?  How do we settle all the possible failure (update
denied) modes?

At the risk of being called a snob, I have very little problems adopting
the philosophy that properly updated PTR records are only afforded to
sites sophisticated enough to run DHCPv6.  Sites that are autoconf-only
can "eat static."*

--tal

* -- "eat static" is an obscure reference to the 2nd Star Trek movie.

---

From: Terry Lambert <[email-masked]>
Date: Tue, 10 Aug 1999 12:04:09 -0700

Tom Limoncelli wrote:
> I visit SomeoneElse, Inc. and plug my laptop into their
> network and use autoconf or DHCPv6 to get an address.
> 
> What should I expect as my FQDN?  Is it tomslaptop.someoneelse.com
> or should I expect the right DNS updates to maintain my name as

Unless you sold your laptop to SomeoneElse, Inc., I think
it should retain its True Name (emphasis intentional).  That
is, it should remain tomslaptop.mycompany.com.

While most of the paranoia on this question ("the travelling
laptop problem") has been directed to "protecting" your DNS
from containing reverse mappings for addresses that are in
your zone of responsibility (and which you are routing),
there is a real issue with your laptop being fooled into
sharing its resources (including its network accessible
filespace) with other machines at SomeoneElse, Inc..

I think that this _requires_ that your laptop retain its
True Name.

> Note: I'm not asking about reverse lookups.  Depending on the
> answer to the question above I have different questions about
> reverse lookups.

Probably the same as my question, only I assumed the above
as a posit, when maybe I should have stated it as an assumption,
like your question does.  8-).

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Tue, 10 Aug 1999 11:47:22 -0700

Masataka Ohta wrote:
> The only reasonable way to go is to abandon stateless
> autoconfiguration except for an isolated small LAN.
> 

This is a nice pie-in-the-sky sentiment which assumes that
people are willing (or even able) to deploy DHCP servers
(presumably US$7000+ NT systems) at dentist's offices.

People won't do this to obtain the dubious benefit of
paying Microsoft ewnough money to purchase an economy
automobile.  Both:

	draft-ietf-dnsind-local-names-07.txt
	draft-ietf-dhc-ipv4-autoconfig-04.txt

specify mechanisms for implementing IPv4 stateless
autoconfiguration for ad hoc networks.  While these
are drafts, they document existing practice, which is
defacto standard (driven by Microsoft's client OS's).

Just because we don't want to do the work to make this
work transparently *and* securely, doesn't mean that
people will not choose to discard security in favor of
convenience to route around, frankly, "our brain damage";
for IPv4, Windows 98 and successors _already_ route
around your desire to control stateless autoconfiguration.

A simple analogy is the "roaming" cell phone.  The cell
phone is permitted to obtain dialtone anywhere, regardless
of whether a particular company likes the idea that someone
could enter their premesis, and place a phone call from
inside their building.  IPv6 Stateless Auto-Configuration
is tantamount to dial tone.  It is ridiculous to consider
trying to control dial tone on a per cell phone basis at
each of the cells.

For IPv4, I think the security argument is specious; in
particular, it's most likely that any ad hoc networking
will find itself occurring behind a network address
translation perimeter, if it finds itself with WAN access
at all.

For IPv6, there is a very real danger that ad hoc networks
will find themselves with non-translated addresses that
give them WAN connectivity.

I will go further: this _will_ happen.  It is expedient,
it is convenient, and it is less work than the alternative.

The only issue is whether your products let them have a
reverse mapping, or not.  If not, and it is found to be an
inconvenience, they will buy someone else's products, and
your point of view loses dejure instead of defacto.

If you wish to make this less likely, the answer is simple:
make what you want to happen be less work for the end user
than what you don't want to happen.

To do this for IPv6, you would have to redefine the entire
autoconfiguration space as non-routable, and requiring
address translation to be routable.  This will happen when
pigs fly, mostly because the routability of addresses
obtained via Stateless Auto-Configuration is intentional:
it was an intended design goal.

Note: IPv4 has defined a mechanism which allows administrative
refusal for Stateless Auto-Configuration of IPv4 Clients:

	draft-ietf-dhc-autoconfig-04.txt

IPv6 (rightly) lacks a similar mechanism, since there is
not a requirement for administrative cooperation for WAN
connectivity (i.e. IPv6 Stateless Auto-Configuration
results in an address that is routable, and does not
require a cooperating Network Address Translation gateway).

As it is, I believe that most printers and other network
attached devices will, in the near (i.e. IPv4) future,
request an address via DHCP, and, failing to find one in
a small business, will engage in IPv4 Auto-Configuration
via the IANA registered LINKLOCAL net.

This will be driven by compatability with Windows 98 and
Windows 2000 IPv4 Auto-Configuration.

After doing this, I expect that there will either be a
vendor proprietary availability broadcast, with a client
installation piece (e.g. HP JetSend), and/or an SLP SA
availability broadcast; this is because these mechanisms
map most closely to what a Windows client in an enterprise
environment would see as a "Network Neighborhood" that
correctly presents the current topology of the network.

Because this will be implemented for enterprises, it will
be used in small offices, such as your dentist's office
example; regardless of the suitability of doing this, I
again predict: this _will_ happen.

People do not want to configure DHCP servers.  Neither do
they want to configure client machines, nor printers.  In
order to expand into the available market, e.g. the small
business, branch office, SOHO market, [read: no MIS department]
vendors must accept this as a reality.

Implementors do not drive technology standards, consumers
do; this is the lesson of VHS vs. Beta.

-- Terry Lambert

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Aug 99 8:15:14 JST

Terry;

> A simple analogy is the "roaming" cell phone.

The roaming cell phone has configured state, which is, to
some extent, kept secret, which is why, unlike stateless
autoconfiguration, it has some security.

> While these

As you know, Microsoft OS has nothing to do with security
a lot to do with stateful configuration.

So?

						Masataka Ohta

---

From: [email-masked]
Date: Wed, 11 Aug 1999 08:56:36 +0900

Terry,

>your point of view loses dejure instead of defacto.

	What do you referring here with the word "security"?  There are many
	"security"-ish things involved here;

	- security of stateless autoconfiguration itself:
		- malicious end node that visits Ethernet hookup in dentist
		  office will get access to other node in the dentist office.
		- (similarly) mailicious user will get global address
		  by stateless autoconfig.
	- malicious router connected to dentist office network will be able to
	  capture every outgoing packets from the dentist office
	- end node at dentist office will automatically be visible to
	  worldwide by using stateless autoconfig

	I suspect you meant the last one, but that is not the only one.
	And the last one is not really true I believe.
	You can announce RAs with site-local prefixes to avoid end nodes to
	be visible from outside world.  I agree that there's no per-host policy
	control about the reachability (there's subnet-grain control only),
	but stateless autoconfig does not always mean worldwide reachability.

	And you seem to say that IPv4 world is safe because you have NAT.
	NAT does not provide security at all.  Malicious outside node can
	inject the inside node any tcp options as he like.

	I maybe missing your point....

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 20:35:39 -0400

>I think that this _requires_ that your laptop retain its

Thats fine and should be acceptable.  My response to Tom was if the DDNS
update was done at the zone domain being visited.

But this has implications not stated here yet.

One of which is to update tomslaptop.mycompany.com address it must do so
at mycompany.com zone, not at SomeoneElse.com zone.  DDNS don't permit
that behavior.

/jim

---

From: Terry Lambert <[email-masked]>
Date: Tue, 10 Aug 1999 17:31:11 -0700

> autoconfiguration, it has some security.

I could argue the cell phone security at length; I won't.

What we are really begging here is the question of why
people believe that one must secure reverse records against
modification by the machine to which the record applies;
what is expected to be won by this?

Paul Vixie's question about whether this is really
applicable to namedroppers contains the assumption
that allowing reverse records to be updated by machines
whose IP address they point to is somehow "bad".  Is
this an autoconfiguration "design flaw", or is it really
a (potentially) invalid assumption about which DNS UPDATE
transactions need to be protected?

I believe this is the question namedroppers must answer,
before the problem can be dropped squarely into the lap
IPNG as "not a DNS problem".

Here are two scenarios for an unsecured reverse record
update for a particular IP address being allowed for
the machine assigned the IP address to which the record
applies.  It is "secured" by: 

o	Ensuring that the machine is only updating the
	record the network implictly granted it ownership
	of by permitting the access by the IP address,
	and the routing its packets

o	Refusing the update if the forward mapping of the
	name does not result in the IP address, a transaction
	requiring authentication or signature

Worst case, we end up with a machine which modifies its
reverse record to not match the forward record using a
two stage process of modifying the forward record twice,
and, again, applications will refuse to talk to it.  We
could work around this by ensuring the TTL on the reverse
is less than the TTL on the forward, or, more anally, we
could verify the forward match each time before responding
to requests for the reverse.

Posit:	If it is insufficient to do forward/reverse checks of
	the DNS for a machine, then it is equally insufficient
	to permit routing of packets for a local address for
	which a reverse mapping does not exist.

Let me know if you think the following scenario list is
incomplete:

Scenario #1:

If we update our reverse record so that it doesn't match
our forward record, applications (e.g. sendmail) will
refuse to talk to us.  There is no benefit to lying about
your host name in a reverse record; futher, the update is
not permitted, if doing so causes it to not match your
forward record.

---

Scenario #2:

On the other hand, if we allow the machine which we admit
currently owns the IP address to modify the reverse record
for that IP address, then we are still protected by the
security applied to the forward record, since the forward
record can enforce a shared secret for machines in its
zone of control.  This enforcement is allowable, because
we presumably have an administrative relationship with
the DNS containing the forward record.

---

Intentional abuse:

Absolutely worst case, we have someone who gets their IP
address at your business (e.g. because you allow them to do
so by not turning off the IR port on the conference table),
updates the forward via a secured method, updates the reverse
because of the relaxed checking, and SPAM's from it using
their own domain name, removing their ability to repeat the
event in the future, and very clearly identifying the
culpable authority.

Alternately, they get an address and an assigned host name
in your address block via DHCP, and SPAM from that, instead,
making you the liable party and damaging the utility of your
non-autoconfiguration space IP address block.  This is worse.

> a lot to do with stateful configuration.

So everyone is going to have to interoperate with Microsoft
software, whether they like it or not; that's just a fact
of life: if you are a server, you have to expect Microsoft
clients for the forseeable future.

-- Terry Lambert

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 21:13:35 -0400

Terry,

I agree with you except for the very last paragraph you sent as that has
some limitations though I agree and understand.  Even that has a test of
reasonability in the market place regarding standards.

/jim

---

From: [email-masked]
Date: Wed, 11 Aug 1999 08:44:19 -0700 (PDT)

> at mycompany.com zone, not at SomeoneElse.com zone.  DDNS don't permit

Where is the security association bound?  Generally my keys are bound to
the machine name (FQDN) that I give it at build time.  DO I have to regen
keys everytime I move?

-- 
--bill

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 1999 20:42:58 +0200

> it is going to be trivial, though I can see it might be possible.

=> I am doing that (I was busy with the eclipse :-).

   I can see some considerable problems if the client initiates
  contact with the DNS servers since typically ND & stateless config
  would probably be done at kernel level.  Usually DNS related stuff
  happens at user level in my experience.  Mixing the two might be a bit
  of a headache, but not impossible.

=> fortunately I do ND prefix discovery & stateless config at user level.

=> it is the thing I have in my TODO.

=> I believe in this case an ICMPv6 service will be better (there are
many proposals and some implementations of this)...

Regards

[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 12 Aug 1999 06:15:15 +1000

Date:        Wed, 11 Aug 1999 22:00:31 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => it is not a new idea and it should be very close to Jim's tool

OK, thanks.   Clearly Jim understood what you were saying, and I was
dreaming ... but thanks for the explanation.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 1999 22:00:31 +0200

=> it is not a new idea and it should be very close to Jim's tool
(it is why I have written "same kind")... The problem is DHCPv6
is not yet available and perhaps will be a bit expensive then
the AAAA & PTR RRs update service should be provided with
the IPv6 stateless address autoconfig (part of the neighbor discovery).

The proposed context is a rather closed environment with security
constraints and a medium term mobility (ie nomadism). Of course
DHCPv6 is the *solution* but again DHCPv6 is not available.

The proposed mechanism is simple:
 1 - stateless autoconfig user daemon signals addition/deletion of
     global prefixes (including old prefixes at boot time)
 2 - suitable AAAA and PTR RRs are updated
 3 - for security DNS updates are signed with TSIG (using pre-shared keys)

Of course for PTR RR updates this may not work with a random server
but this works inside an organization, even a large one.

[email-masked]

PS: the first step is to get a working dynamic update for IPv6,
both in client and server (Jim has already that).

---

From: Jim Bound <[email-masked]>
Date: Thu, 12 Aug 1999 11:24:44 -0400

> the machine name (FQDN) that I give it at build time.  DO I have to regen

I would not think so?  Your binding is the FQDN server as you put it
back home. ??????????

/jim

---

From: [email-masked]
Date: Thu, 12 Aug 1999 08:29:26 -0700 (PDT)

> I would not think so?  Your binding is the FQDN server as you put it

so, my FQDN & keys are instantiated at system build time. When I "wander"
I pick up a new IP address and dynamicDNS should allow me to have the new
address bind to my FQDN, not some local fabrication, yes?

-- 
--bill

---

From: Jim Bound <[email-masked]>
Date: Thu, 12 Aug 1999 12:44:27 -0400

> address bind to my FQDN, not some local fabrication, yes?

That is essentially how I think it should work.  Mobile nodes need to
not have to re-figure out all this is why.  But we should really hear
from Donald and other folks to verify what we would like can happen.

As long as your going back home toto only though...If you try to do
stuff at the site your visiting you got to redo the key part to get
through that server.

/jim