Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 09 Jun 2002 10:16:41 -0400

In message <[email-masked]>, Pekka Savola 
writes:
>On Sun, 9 Jun 2002, Ralph Droms wrote:
>> problem.  A router can't know when it's forwarding a packet outside of a 
>> site unless it's been configured with information about site borders.  So 
>> network architects and admins have to define what makes up sites and 
>> configure the routers at the borders to know about those site 
>> borders.  And, I don't think there's a good way to define default behavior 
>> or auto-discovery for site-local addressing...
>
>Precisely.

Yup -- and now we're elevating it to an architectural principle.
> 
>> I don't see much difference between RFC 1918 addresses and site-local 
>> addresses in the areas of network design and deployment...
>
>Me neither.  More probable outcome is that someone starts to request that
>people implement NATv6, because 1) they're already used to it (and like
>its "security") in v4 world, and 2) they think it's easier for them to do
>NAT than to renumber.
>
>Site-locals were born in the era that not all sites had internet
>connectivity.  Now that assumption is not all that valid anymore.  It's
>just easier for people to use a global address block (even if we define
>that address block to be 3ffe:eff3::/32 or whatever) even with these
>"internal needs" (note: I believe there should be _something_ that does
>not require you to fill any kind of paperwork).
>

Yah.  Let's pick a prefix, and tell folks to pick a random number (more 
precisely, use an RFC 1750-compatible RNG) to fill out the rest of the 
high-order bits to a /48 or a /64.  We encourage ISPs to provide real
prefixes to companies that are using application-layer gateways, and 
hence don't "need" a routable prefix.  We promise two months of 
connectivity to folks using non-conflicting random prefixes when they 
connect, while they renumber.  We think of other, creative solutions 
that exploit the fact that we have a really large address space that 
we're not going to exhaust.  

In short, that we do *something* that isn't going to cause long-term 
architectural and operational pain.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Sun, 09 Jun 2002 10:38:23 -0400

Steve,

> architectural and operational pain.

I suggested several years ago that the site-local prefixes could
contain more info to help "identify" it.  I was told that it had
been discussed and was not beneficial enough.  Adding an AS # or
some other identifier would definitely help clarify the prefixes.

Brian

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 9 Jun 2002 12:11:44 -0700

Steven M. Bellovin wrote:
> In message
> <[email-masked]>, Pekka Savola
> writes:

While I am all for avoiding architectural and operational pain, I don't
see this is as big a deal as the thread seems to be making it out to be.
There is no need for fixing the IGPs to deal with SiteLocal as they run
within the context of the site, therefore shouldn't know about any other
sites. Implementations where a given router will have an interface in
multiple sites will need a way to tag and keep each IGP isolated. The
simplest way is to track which interface the IGP message comes in on and
make sure it maps to the corresponding IGP process.

I think most of this thread is focused on what are simply implementation
details, not an issue for the standards per se. The biggest issue I saw
was related to DNS returning SL or not, and this is not an issue as long
as the DNS server is not expected to deal with multiple sites. As long
as routing is filtering SL at the borders, the only way a DNS query
would get to the SL of the DNS server would be within a site, and the
only reason a DNS server should return an SL address is if the query was
addressed to its SL address. Maybe this needs to be stated clearly in
the ngtrans doc on DNS issues, but this should be obvious from the
perspective of 'don't return an answer that can't be used'.

What this means is that an SP will not provide SL addresses for
customers. This is not a problem today, unless an SP DNS is resolving to
RFC1918 addresses.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 09 Jun 2002 19:07:39 -0400

Hi Tony,

>sites. 

This is not necessarily true.  There is no restriction on that site borders
must match IGP or EGP routing borders of any kind.  

If we could require some relationship between site borders and routing
protocol borders, it might make things easier.  However, it is unclear
which border it would make the most sense to pick.

Margaret

---

From: Allison Mankin <[email-masked]>
Date: Sun, 09 Jun 2002 19:49:34 -0400

> and the 

I would question whether this is well-understood and DNS servers
are ready to select which AAAA records to reply with depending
on the address the query was sent to.  Do current servers implement
this, including caching servers?

Allison

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Jun 2002 17:07:18 +0900

>>>>> On Sun, 09 Jun 2002 19:49:34 -0400, 
>>>>> Allison Mankin <[email-masked]> said:

> this, including caching servers?

BIND 9 servers could do this in the sense that they can change a zone
in question based on the query's destination, but I don't think this
feature handles the case in this thread.

Anyway, I don't think the issue about site-local addresses and DNS is
that simple.  The point is that DNS is a global database while the
notion of scoped addresses is not global (there is nothing new about
the gap, though.  this should have been discussed many times in the
context of IPv4 private addresses and DNS).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Mon, 10 Jun 2002 16:19:41 +0700

Date:        Sun, 09 Jun 2002 19:49:34 -0400
    From:        Allison Mankin <[email-masked]>
    Message-ID:  <[email-masked]>

  | I would question whether this is well-understood and DNS servers
  | are ready to select which AAAA records to reply with depending
  | on the address the query was sent to.  Do current servers implement
  | this, including caching servers?

It is much worse than that - just imagine a DNS server running on a
site border router (which is much more likely in some environments than
others - but in those ones, it is quite plausible).   How such a server
figures out which particular site local AAAA records it should forward
into which site, even assuming that the DNS server is actually taught
about sites, is mind blowing.

This all could be kind of managed if Paul Francis' NUSLA proposal were
adopted (see the message I just sent) but without that, I thought that we
had pretty much concluded ages ago that putting site local addresses in
the DNS (other than for people using site locals for the purpose of
running a disconnected net, where those are the only addresses that exist)
was a total write off as an idea.   Sure it can be made to work in
particular cases with special care (just as sticking 1918 addresses in
the DNS can be coerced into working) - but it isn't something that anyone
rational would ever actually suggest as SOP.

What we need is a way to decide when to use site local addresses, and
to discover what the appropriate address is, that does not use the DNS.
I think that's entirely possible, and certainly don't believe that the
current lack of a specification for how to do it warrants discarding site
local from the architecture (though it probably warrants suggesting
extreme caution in their use for now).

kre

ps: Aside: note we have no process problem advancing the specs we have
with site local remaining in them - we have enough implementations of
site local, which work as much as the spec says they should work, which
isn't very much, for the specs to be able to advance as they are.

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Jun 2002 14:43:08 -0700

On Sunday, June 9, 2002, at 12:11 PM, Tony Hain wrote:

> as the DNS server is not expected to deal with multiple sites.

An issue that is overlooked in this discussion is reverse path
DNS lookup for site local addresses.

Today, with IPv4+NAT on my home network, I simply point my
stub-resolvers to my ISP DNS resolver. It's simple, and works
fine, at least until I try to do reverse DNS lookup for my internal
addresses. Then it just fails. Some applications that I run on
my local LAN don't work well or wait forever for timeouts,
because they can not resolve 1.1.168 .192.in-addr.arpa.
If I had enough IPv4 address space, I could get my ISP
to populate the DNS reverse maps, and my problem would
be solved.

I would expect that IPv6 will help me here by giving me a
global prefix (although I agree that getting my ISP to populate
a v6 reverse map is somehow more complex than in IPv4),
but if, according to the address selection rules, my system will prefer
site local addresses for internal communication, amd I'll back to square 
1.

	- Alain.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 11 Jun 2002 11:18:54 +0900

>>>>> On Mon, 10 Jun 2002 14:43:08 -0700, 
>>>>> Alain Durand <[email-masked]> said:

> site local addresses for internal communication, amd I'll back to square 

(this is not directly related to the site-local address issue any
more)

Aside from whether site-local addresses are good, acceptable, or bad,
I believe the described problem means we'll have to try to not rely on
the reverse lookup in IPv6 much more than in IPv4.
draft-ietf-dnsop-inaddr-required-03.txt should be taken seriously in
IPv6.

					JINMEI, Tatuya

---

From: [email-masked]
Date: Tue, 11 Jun 2002 11:29:47 +0900

>> site local addresses for internal communication, amd I'll back to square 

	there are at least three major reasons why DNS reverse mapping do not
	work with scoped address.

	(1) global nature of DNS directly conflicts with scoped address model.
	(2) DNS wire packet format only uses 128bits.
	(3) the querier of the reverse mapping differs from
	the machine holding the database, thus the view of the scope is
	different (and there's no way of identifying particular scopes,
	like "this subnet" or "this site"").

	if the querier could directly resolve the reverse mapping, we could
	solve the problem.  here's one of my proposed solution.  some may not
	like it, specifically dnsext folks...

itojun

Internet Engineering Task Force                 Jun-ichiro itojun Hagino
INTERNET-DRAFT                                   IIJ Research Laboratory
Expires: November 17, 2002                                  May 17, 2002

      Use of ICMPv6 node information query for reverse DNS lookup
              draft-itojun-ipv6-nodeinfo-revlookup-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be November 17, 2002.

Abstract

The document proposes an alternative way to perform reverse DNS lookup,
by using ICMPv6 node information query/reply [Crawford, 2002] .  The
proposed protocol works only with IPv6 (not with IPv4).

1.  Motivation

As documented in [Senie, 2001] , even though many applications assume
reverse address mapping to exist, DNS reverse address mapping table may
not be present.  With IPv4, automatically-generated reverse mapping
table, like following, has been used.

     123.123.123.123.in-addr.arpa. IN PTR 123-123-123-123.reverse.example.org.

However, it is difficult to provide such mapping for IPv6, due to the
number of reverse mapping records needed.  Therefore, with IPv6, it is
more likely to see IPv6 addresses without reverse DNS mapping.  While it
may be possible to register reverse DNS records via dynamic DNS updates,
it is still not widely practiced due to difficulties with authentication

ITOJUN                 Expires: November 17, 2002               [Page 1]


DRAFT         ICMPv6 node info query for reverse DNS lookup     May 2002

(distribution of TSIG authentication keys).  Also, reverse DNS lookup
based on PTR record can cause more delay to applications than IPv4 case,
as an IPv6 reverse DNS mapping requires much more of NS indirections (34
levels rather than 6 levels).

Another problem is that DNS PTR records do not support scoped IPv6
addresses well, as DNS infrastructure is global in nature and there is
no way to differentiate between scope zones.

For this reason, this document discusses an alternative way to provide
reverse DNS lookups.  The approach uses ICMPv6 node information
query/reply [Crawford, 2002] .

2.  Protocol

There are two parties: querier and responder.  The querier knows an IPv6
address of the responder, and is interested in getting fully-qualified
DNS name for the responder,

Querier transmits the following ICMPv6 node information query packet to
the reponder's address:

     IPv6 source: one of querier's address (Q)
     IPv6 destination: responder's address (R)
     Code: 0 (Subject is an IPv6 address)
     Qtype: 2 (DNS name)
     Nonce: pseudo-random (N)
     Data (Subject): responder's address

In response, the reponder transmits ICMPv6 node information reply with
fully-qualified DNS name.

     IPv6 source: one of responder's address
     IPv6 destination: Q
     Code: 0 (Successful)
     Qtype: 2 (DNS name)
     Flag: lowermost bit set (TTL is valid)
     Nonce: N
     Data: fully-qualified DNS name.
          TTL must be set based on R's address lifetime.

Note:

o The IPv6 source address of the reply need not be R; Nonce field should
  be used to match replies against a query.

o Fully-qualified DNS name must be sent on replies.  If DNS name on the
  reply is a single-component name, the querier should ignore the
  response.

o Administrators are advised to provide consistent reverse mapping with
  forward DNS record, where possible.

ITOJUN                 Expires: November 17, 2002               [Page 2]


DRAFT         ICMPv6 node info query for reverse DNS lookup     May 2002

Querier is allowed to retransmit query 3 times with 1 second interval.

Querier should implement cache mechanism, based on the TTL value sent
from the responder.  If TTL value is not present on replies, querier
must not cache values on replies.  If there is no response after 3
retransmissions, negative-cache entry with lifetime of 30 second should
be installed.

Querier must ignore responses with a Nonce value unknown to the querier
(it could be a malicious attempt to taint the cache).

Responder must rate-limit replies as documented in ICMPv6 node
information query document [Crawford, 2002] .

3.  Appicability

3.1.  Is "DNS name" on the reply really a DNS name?

Responses returned on "DNS name" query can contain arbitrary string
independent from deployed DNS infrastructure.  For example, any node can
respond with DNS name "foo.example.org" without example.org
administrator's knowledge.  This is also true for reverse DNS mapping
based on PTR records.

3.2.  Consistency with forward DNS records?

We cannot assume consistency with forward DNS records.  It is the same
as DNS PTR records.

With scoped IPv6 address, it is not possible to keep consistency between
forward and reverse mapping (both with DNS PTR records and ICMPv6 node
information queries), as it is discouraged to put scoped IPv6 address
into global DNS database, and there is no DNS PTR delegation for scoped
IPv6 addresses.

3.3.  Number of configured elements?

With DNS PTR records, the reverse address mapping needs to be configured
on DNS server.  With ICMPv6 node information query, all nodes need to be
configured with fully-qualified DNS name.

3.4.  Interaction with scoped IPv6 addresses

DNS PTR records do not support scoped IPv6 addresses well, due to the
following reasons:

o DNS database is a global database in nature, and does not fit well
  with scoped IPv6 address.

o ip6.arpa (or ip6.int) delegation structure does not deal with scoped
  delegation.

ITOJUN                 Expires: November 17, 2002               [Page 3]


DRAFT         ICMPv6 node info query for reverse DNS lookup     May 2002

o The view of scope zones differs from nodes to nodes.  Therefore, if
  the querier node of DNS PTR record is different from the node holding
  DNS PTR database, they have different idea about/access to scope
  zones.

o There is no way to differentiate between scope zones, specifically
  from remote.

ICMPv6 node information query/reply handles scoped IPv6 address well, as
the querier directly tries to obtain reverse name mapping (hence there
is no difference in the view of scope zones).

Even with ICMPv6 node information query/reply, it is not possible to
provide a consistent mapping between forward and reverse lookup for
scoped IPv6 addresses, as DNS wire packet format (AAAA) does not have a
way to identify scope zones.

4.  Security consideration

4.1.  Are there any possibility for forgery?

Yes.  Intermediate nodes can intercept node information query/reply
packet and throw in forged queries/replies.  It is true for DNS
query/reply too.

There are ongoing efforts in DNS arena for data integrity protection -
DNSSEC.  It is a bit hard to do similar thing for node information
query.  DNSSEC is possible because there is NS delegation tree in DNS.
There is no obvious "structure" in node information query.

4.2.  Use of reverse DNS mapping for authentication

As documented in [Senie, 2001] it is discouraged to use the existence of
reverse DNS mapping as authentication.

References

Crawford, 2002.
Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg-
icmp-name-lookups-09.txt (May 2002). work in progress material.

Senie, 2001.
Daniel Senie, "Requiring DNS IN-ADDR Mapping" in draft-ietf-dnsop-
inaddr-required-02.txt (July 2001). work in progress material.

Change history

None.

ITOJUN                 Expires: November 17, 2002               [Page 4]


DRAFT         ICMPv6 node info query for reverse DNS lookup     May 2002

Acknowledgements

(to be filled)

Author's address

     Jun-ichiro itojun HAGINO
     Research Laboratory, Internet Initiative Japan Inc.
     Takebashi Yasuda Bldg.,
     3-13 Kanda Nishiki-cho,
     Chiyoda-ku,Tokyo 101-0054, JAPAN
     Tel: +81-3-5259-6350
     Fax: +81-3-5259-6351
     Email: [email-masked]

ITOJUN                 Expires: November 17, 2002               [Page 5]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jun 2002 09:18:17 +0300 (EEST)

On Mon, 10 Jun 2002, Alain Durand wrote:
> addresses. 

You could run your own authorative DNS server in your
router/firewall/whatever.  That's what I do.  That isn't really a recipe
for the masses, but if that's all it takes, I guess router vendors might
implement something like that.

> Then it just fails. Some applications that I run on

Wildcard records (shudder) ?
 
-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Jun 2002 14:43:08 -0700

- Alain.