Subject: [dnsop] ISSUE 8:reverse-mapping-considerations: IP version neutrality

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Oct 2006 15:22:01 -0400

ISSUE
=====

The document talks about IN-ADDR, which is IPv4 only, but is really
about reverse mapping.

PROPOSAL
========

The text makes explicit that any IN-ADDR references apply equally to
all relevant functionality in other IP versions.  If this is not
clear in any part of the document, though, it will undermine the
effectiveness of the document, so additional objections of this kind
are solicited.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Joe Abley <[email-masked]>
Date: Mon, 23 Oct 2006 15:59:50 -0400

> effectiveness of the document, so additional objections of this kind

Why not use a different phrase instead of "IN-ADDR"? Why not define  
"reverse mapping" and use that instead?

Joe

.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 23 Oct 2006 22:57:21 +0200

Reverse DNS is often quite different in IPv6 compared to IPv4. In IPv6 end users
likely get a /48, or perhaps a /64 rather than a small number of IPv4 addresses.

The reverse delegation either needs be a delegation to some device on the end
user premise, or the end user needs to have some (presumably secure) way of
updating the zone at their upstream (could be dynamic DNS, but doesn't need to be).

I would recommend leaving IPv6 out of the document, or perhaps note that it is a
different problem.

.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Oct 2006 17:09:40 -0400

> I would recommend leaving IPv6 out of the document, or perhaps note that it is a

Ok, but that entails limiting the scope more narrowly than the
document has been limited so far.  Is there any way to make the
recommendations consistent across address types, without making the
recommendations too narrow for actual IPv6 users (or conversely, for
IPv4 users, _mutatis mutandis_)?  Alternately, if this is to be an
IPv4 doc only, does the group want an explicit note to the effect
that we're leaving IPv6 for another day?

A

.

---

From: Joe Abley <[email-masked]>
Date: Mon, 23 Oct 2006 21:20:39 -0400

On 23-Oct-2006, at 16:57, Shane Kerr wrote:

> Reverse DNS is often quite different in IPv6 compared to IPv4.

I think I would be more likely to characterise it as being identical  
in approach, and differing only in minor details.

> In IPv6 end users

Details! :-)

> updating the zone at their upstream (could be dynamic DNS, but  

This is as true for IPv4 as it is for IPv6, and in neither case does  
it actually matter where the nameservers are located.

> I would recommend leaving IPv6 out of the document, or perhaps note  

I think it's the same problem, and can therefore see no reason to  
leave it out.

Joe
.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 24 Oct 2006 11:29:46 +0200

Joe,

Joe Abley wrote:
> This is as true for IPv4 as it is for IPv6, and in neither case does it
> actually matter where the nameservers are located.

In theory it is as true for IPv4 as it is for IPv6, but in practice I don't
think that it is.

For almost all home users and many business users, the ISP manages the IPv4
addresses. In this case, there is no need for:

- - Software of any sort on the site where the addresses are used
- - Any exchange of secret between the end user and the upstream

The ISP simply publishes some reverse name for the address, typically based on
the ISP's own topology or sometimes the customer can request some particular name.

In IPv6, the ISP has no knowledge of which of the 2^64 or 2^80 addresses given
to each customer is actually used for which purpose. This is why I suggest that
for reverse DNS to work in IPv6 you need to either delegate to a DNS server that
is at the customer site or provide some way to update the DNS information at the
ISP's server.

If ISPs decide to manage customer addresses directly, for example with DHCPv6,
then this problem does go away. Perhaps the DNSOP group would like to propose
moving IPv6 stateless address configuration to "historical" and recommend using
DHCPv6? ;)

- --
Shane
.

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Oct 2006 10:08:14 -0400

> that we're leaving IPv6 for another day?

I haven't asked, but I strongly suspect that the IESG would push back
on any attempt to publish this as an IPv4-specific document.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Oct 2006 11:22:38 -0400

> is at the customer site or provide some way to update the DNS information at the

So would a note to the following effect address your concern (say, in
section 3.2 of the doc):

    IPv6 reverse mapping is conceptually the same as IPv4 reverse
    mapping, but operators are reminded that, depending on details of
    address and DNS management, it may be more complicated to ensure
    that reverse mapping remains accurate under IPv6.  In particular,
    operators are urged to consider the number of addresses each
    customer might have when developing a scheme to support reverse
    entries.  Administrators are advised to consider the potential
    for inaccuracy (or generic entries) in large blocks of IPv6 space
    when contemplating using reverse-mapping tests.

?

A
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Oct 2006 20:00:24 +0300 (EEST)

> moving IPv6 stateless address configuration to "historical" and recommend using

RFC 4472 discusses all these issues.  There's probably some material 
there that could be pulled here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Oct 2006 14:28:02 -0400

> there that could be pulled here.

Thanks, that's the reference I need.  I don't know that the material
needs actually to be added; a reference ought to be enough, right? 
Shane, would a note referring specifically to 7.2 through 7.5 of RFC
4472 address your objections?

A

---

From: Shane Kerr <[email-masked]>
Date: Tue, 24 Oct 2006 21:50:23 +0200

> 4472 address your objections?

If reverse for IPv6 is useful to some people, then they will use it. Otherwise,
they won't.

I hate to be a weenie, but I think it is a mistake to encourage its use.

The cost of maintaining IPv6 reverse information is significantly higher than in
IPv4, and the benefits are even less.

I'm sorry if this will make the IESG unhappy, but RFC 4472 only reinforces this.

Does everyone on this list disagree with me?

- --
Shane
.

---

From: [email-masked]
Date: Tue, 24 Oct 2006 21:15:22 +0000

tough to speak for "everyone" ...  but i disagree with your stated
 position.  either the DNS is useful or not.  if not (too hard, etc)
 then we should dump it.  if it is, then we should use it and strongly
 encourage its use.  now i'm all for the re-introduction of address
 literals as opposed to the DNS lable redirection thing...  it would 
 have the pleasing side effect of moving the riffraff that clog the Internet
 off onto some other (likely walled-garden) network.  but then what
 would dnsops do?

--bill (checking his cheek for foreign objects)

On Tue, Oct 24, 2006 at 09:50:23PM +0200, Shane Kerr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew Sullivan wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFPm5/MsfZxBO4kbQRAn2mAKDoPFIEfGd+V0Ij+OsEmIpAdfRQpACeKjmC
> y1k3EHb0FBP4UMTdrzpLhyA=
> =j4iQ
> -----END PGP SIGNATURE-----
> .
.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Oct 2006 11:57:00 +1000

> Does everyone on this list disagree with me?

	There are sites now that don't allow you to send them email
	over IPv6 unless there is a valid reverse lookup.  This
	will not change.

	Is it really that hard to automate the "delegation" of
	reverse namespace?  Even for sites that get a new prefix
	each time they connect to the network it should be no
	more work that adding a DNAME.  For relatively static
	networks the traditional NS delegations will work.

	We have the technology to do this now in a authenticated manner.

	Isn't it about time we allowed home networks to become first
	class citizens?  Lot's of the problems we see on the network
	today are caused be treating home networks as second class
	citizens.

	* Having to use a bogus domain name internally.
	* Forcing home networks to use RFC 1918 address space.

	I would like to see ISP's offer both forward and reverse
	(dynamic?) DNS services for home customers.  To supply
	a forward domain for home customers that don't need a
	fancy name.  e.g. <custname>.customer.<isp'sname>

	The above DNAME would become something like the following
	for the typical home customer.

	1.2.3.4.1.2.3.4.1.0.0.2.ip6.arpa DNAME ip6.<custname>.customer.<isp'sname>
	
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Shane Kerr <[email-masked]>
Date: Wed, 25 Oct 2006 08:53:05 +0200

> Does everyone on this list disagree with me?

So, to answer my own question, "yes". :)

Andrew: In the end I guess it's best to refer to RFC 4472, if you need to
include ip6.arpa in this document.

One final thing to think about on my way out the door from this thread after
being beaten with varying degrees of gentleness by the group:

Does anybody on this list have a /48 or /64 delegation? Does anybody also have a
working reverse DNS setup from their provider? (For me, it's "yes" and "no".)

I've used IPv6 in a few different environments, and have never seen a working
reverse when stateless auto-configuration is used. Isn't it weird to recommend
people implement a practice that is rare (or non-existent)?

- --
Shane
.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Oct 2006 13:37:17 +0300 (EEST)

> people implement a practice that is rare (or non-existent)?

Did you mean a /48 or /64 delegation to a residential broadband user 
or something like that?  Because reverse DNS for v6 is commonplace 
(AFAICS) for bigger endsites and I'm not sure if you're disputing 
that.

My enterprise has a /48 from a PA block, and also has reverse 
delegation.  At my other job, we always delegate reverse DNS (this 
includes v6 as well) to the (enterprise/university/etc.) customers.  
Until the customer has configured the reverse delegation properly, we 
don't even route their traffic.

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Oct 2006 08:23:55 -0400

> working reverse DNS setup from their provider? (For me, it's "yes"  

For me it's "yes" and "yes", but I doubt I am normal in that respect.

> people implement a practice that is rare (or non-existent)?

I think it's rare because the tools don't make it easy to do the  
right thing. Perhaps some organisation with experience with the DNS  
should write some patches to rtsold :-)

I think perhaps the situation is different in environments where  
Microsoft's Active Directory is in use? I have next to no experience  
of AD, but I was under the impression that krb5-authenticated dynamic  
updates of the forward and reverse zones by clients was part of the  
package.

If the client is equipped with authorisation credentials to make  
updates and is capable of signalling (name, address) bindings on its  
own, then I guess it doesn't matter whether you get your v6 addresses  
through stateless auto-config, or dhcp6, or something else.

Joe
.

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 Oct 2006 14:04:25 +0100

> For me it's "yes" and "yes", but I doubt I am normal in that respect.

We're probably in the same boat as Joe, on the 'yes'/'yes' front.
 
> should write some patches to rtsold :-)

We don't use AD, or dynamic DNS, for IPv6, rather we rely on manual DNS 
additions (which through scripts generate reverse DNS).   But that's 
clumsy, even for just a few hundred hosts.

We're waiting on DHCPv6 client and server software to deploy a similar
solution to what we have for IPv4 now.   The ISC development is thus 
very interesting for us, as is DHCPv6 client support in Vista.   But
that's still future gazing.

There's also the mud of 3041 addresses, which add complexity if you
hope to use reverse DNS as a weak auth mechanism.  
 
-- 
Tim

.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 26 Oct 2006 14:18:40 +0100

> working reverse DNS setup from their provider? (For me, it's "yes"  

Yes, and partly.  Provider side just works, as might be expected from  
sixxs. 8-)
On my side, I have a list of things to fix -- any weekend now...

/Niall

.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Oct 2006 01:12:20 +1000

> On my side, I have a list of things to fix -- any weekend now...

	Yes (/64) and yes (0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa).
	He.net's tunnel broker also offers the ability to delegate
	the reverse zone.

	My cable provide doesn't support IPv6 currently.

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 26 Oct 2006 06:20:09 -1000 (HST)

> working reverse DNS setup from their provider? (For me, it's "yes"

Yes.  Our policy has always been to delegate if the customer requests it 
regardless of IP version.  However, with IPv4 on non-octet boundaries it's 
a real pain so we discourage it for anything more specific than a /24.

Antonio Querubin
[email-masked]
.

---

From: Joe Abley <[email-masked]>
Date: Thu, 26 Oct 2006 13:29:05 -0400

On 26-Oct-2006, at 12:20, Antonio Querubin wrote:

> However, with IPv4 on non-octet boundaries it's a real pain so we  
> discourage it for anything more specific than a /24.

Just out of interest, is the primary source of pain having to deal  
with confused customers, or something else?

Joe
.

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 26 Oct 2006 10:49:49 -1000 (HST)

On Thu, 26 Oct 2006, Joe Abley wrote:

> Just out of interest, is the primary source of pain having to deal with 
> confused customers, or something else?

Mainly the latter.  The setup isn't a trivial NS RR that points at the 
customer's DNS like you would for a whole /24.  You have to setup a CNAME 
for each IPv4 address the customer wants to have delegated.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Oct 2006 09:29:55 +1000

> for each IPv4 address the customer wants to have delegated.

	I don't know which nameserver you actually use but with some
	nameservers it is no harder than adding a extra line.

	e.g.

	<first>-<last> 	NS ns1.customer.
	<first>-<last> 	NS ns2.customer.
	$GENERATE <first>-<last> $ CNAME $.<first>-<last>

		or 

	<base>/<cidr>	NS ns1.customer.
	<base>/<cidr>	NS ns1.customer.
	$GENERATE <first>-<last> $ CNAME $.<base>/<cidr>

		or

	<first> 	NS ns1.customer.
	<first> 	NS ns2.customer.
	$GENERATE <first+1>-<last> $ CNAME $.<first>

		or

	$GENERATE <first>-<last> $ CNAME $.<arbitary-forward-zone>

	Note all of the above are simpler overall (parent and child) 
	than delegating the entire range using a normal delgation
	as the child then has to setup multiple zone.  One for each
	address

	$GENERATE <first>-<last> $ NS ns1.customer.
	$GENERATE <first>-<last> $ NS ns2.customer.

	RFC 2317 style delegations do not increase the workload for
	the parent over traditional delgations and in may cases
	significantly reduce the work load.  The record counts of
	all the RFC 2317 style delgations above are less than those
	required for a traditional delegation.

	Mark

---

From: Simon Leinen <[email-masked]>
Date: Sun, 29 Oct 2006 18:50:20 +0100

Shane Kerr writes:
> The cost of maintaining IPv6 reverse information is significantly
> higher than in IPv4, and the benefits are even less.

Hm, I'm not sure I agree with either of these:

While there are factors that make reverse mapping harder to maintain
in IPv6 than in IPv4 (address auto-configuration), there are also
points that make it easier.  In particular, address space is almost
always delegated at inverse-DNS-friendlier boundaries.

While there are factors that make reverse mapping less useful for IPv6
than for IPv4 (address auto-configuration), there are also points that
make it more useful.  In particular, IPv6 addresses are harder to read
and remember than IPv4 addresses, therefore the added convenience of
mapping to hostnames is higher.
-- 
Simon.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 30 Oct 2006 14:18:02 +0900

(resending it from a different mail address...)

>>>>> On Wed, 25 Oct 2006 08:53:05 +0200, 
>>>>> Shane Kerr <[email-masked]> said:

>> Does everyone on this list disagree with me?

On one hand, I agree that maintaining IPv6 reverse mappings is more
difficult than for IPv4, and that why it is so may not always be a
minor detail.

On the other hand, I see reverse mappings provide useful information
(whether it's for IPv4 or IPv6) in some cases such as in traceroute
output.  So, I'm fine with encouraging operators to maintain reverse
mappings.

In my opinion, the problem is not whether to encourage maintaining
reverse mappings; it's why we encourage so.  As long as we understand
a reverse mapping is an optional hint which may or may not be
available, encouraging the maintenance of the mappings does no harm.
However, if we heavily rely on the existence of a reverse mapping such
as in some form of authentication, the difficulty of deploying IPv6
reverse mappings will cause more serious troubles.

So I think this is actually a matter of different issue:

5.	The recommendations in section 4 are not strong enough.
(which was in the original issue list given in
http://www.uoregon.edu/~llynch/dnsop/msg03661.html)

It's not directly related to the "IP version" issue, so I'll make a
separate thread on this point.

> working reverse DNS setup from their provider? (For me, it's "yes" and "no".)

For me, the answer is yes and yes, although not all IPv6 addresses in
use under the /48 prefix are registered in our reverse mapping domain.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html