Subject: Comment on draft-ietf-ipngwg-addrconf-privacy-02

From: "Matt Crawford" <[email-masked]>
Date: Thu, 03 Aug 2000 13:07:35 -0500

Please remove the suggestion that DNS servers 'fabricate
"dummy" answers'!  The alternative, that nodes register
random names, is fine.
				Matt
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Stig Ven�s <[email-masked]>
Date: Thu, 3 Aug 2000 21:45:45 +0200

> "dummy" answers'!  The alternative, that nodes register

How about registering a PTR record for the prefix, if some server can't
find a PTR record for the address, it could at least find out who owns
the prefix. The result would be just as meaningful as a zone full of
random names.

Stig

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 04 Aug 2000 09:45:35 -0500

> the prefix. The result would be just as meaningful as a zone full of

That would require the pesky servers (the ones demanding to
find your reverse mapping) be modified.  It's not likely to
happen.
				Matt
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 04 Aug 2000 09:46:54 -0500

> My suggestion was to use a wildcard PTR record for the /64 subnet.
>     - Alain.

That ought to do the trick.

---

From: "Alain Durand" <[email-masked]>
Date: Thu, 3 Aug 2000 13:01:09 -0700

- Alain.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Aug 2000 15:25:13 -0400

"Matt Crawford" <[email-masked]> writes:

> "Alain Durand" <[email-masked]> writes:
> 

> That ought to do the trick.

Would it? I thought the basic problem is that some servers require
that a PTR record for an address point to a name, and that the
returned name also map back to the address being used. I.e, the issue
isn't just lack of a PTR record.

The current text in the draft still needs changing then though, as the
text that Matt asks to remove really needs to spell out that
"fabricate dummy answers" means for both the reverse and forward
directions. Not something I think is such a great idea.

So, unless I hear otherwise, I will remove the text as suggested.

Thomas

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 25 Aug 2000 15:56:47 -0500

> isn't just lack of a PTR record.

I have only run into one instance of such a picky-server problem, and
I've been in the situation for a couple of years.  My home subnet is
statically assigned but the [IPv4] ISP won't point the PTRs to my
names, although the forward mappings, which are under my control,
point to the ISP-assigned addresses.  The only problem this seems to
cause is that the MX servers for aol.com won't accept my email unless
I funnel it through the ISP's smtp server.

All other servers seem to be satisfied as long as there's SOMETHING
in the in-addr.arpa.

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Aug 2000 15:08:07 -0700

> isn't just lack of a PTR record.

For application like rlogin (and .rhost mechanism), you're right...
But such mechanisms are trying to identify you from your IP address,
so using an address generated according to the privacy draft in such a context
will clearly not work...

    - Alain.