Subject: Re: another renumbering question

From: "Matt Crawford" <[email-masked]>
Date: Thu, 08 Feb 2001 11:06:31 -0600

> > > > Why would any enterprise publish the A record of 
> > > > internalserver.example.com
> > > > outside the firewall?
> > > 
> > > Why wouldn't they?   
> > 
> > Truly, you are out of touch with the way large corporate 
> > intranets are run.
> 
> no he is not.  I know three large corporations using the fact that they got
> nice large ipv4 address space and do this in totally secure manner.

Putting aside who said what, the second person may or may not be out
of touch with they way many large (and small) organizational (not
just corporate) networks are run, but may just be more *in* touch
than those organizations are with what consititutes Real(TM) Security.

We here all know that hiding names and addresses isn't "real"
security.  But it's on a lot of checklists.  People with the smarts
and backbone to criticize the checklists are often not in the right
organizational place to get them changed.
--------------------------------------------------------------------
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 E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2001 11:09:04 -0600

I really think you're missing my point, which is that this is nothing to do
with NAT; people were hiding internal-only hosts for years before NAT came along,
and they always will. This is nothing to do with address space. Your border
router doesn't route unsolicited packets to the hidden host and your external 
DNS doesn't propagate its RRs. Hiding site-local addresses is no different.

  Brian

[email-masked] wrote:
> nice large ipv4 address space and do this in totally secure manner.  the
> evil here is nat your concerned about and site local addresses can cause
> that evil again.  also many of the ietf mantras are getting trashed in the
> real world.  we need to update our mantras.
> 
> /jim
> 
> > -----Original Message-----
> > From: ext Brian E Carpenter [mailto:[email-masked]]
> > Sent: Thursday,February 08,2001 11:28 AM
> > To: Robert Elz
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: another renumbering question
> >
> >
> > Robert Elz wrote:
> >
> > >   | Why would any enterprise publish the A record of
> > >   | outside the firewall?
> >   Brian

---

From: Greg Maxwell <[email-masked]>
Date: Thu, 8 Feb 2001 12:15:50 -0500 (EST)

On Thu, 8 Feb 2001, Matt Crawford wrote:

[snip]
> organizational place to get them changed.

.. and there are quite a few 'security professionals' with a vested
financial intresting in selling security solution packages that include
such useless protections especially once which increase support and
maintance expenses.

---

From: [email-masked]
Date: Thu, 8 Feb 2001 10:27:24 -0600

/jim

---

From: Greg Maxwell <[email-masked]>
Date: Thu, 8 Feb 2001 15:42:39 -0500 (EST)

On Thu, 8 Feb 2001, Brian E Carpenter wrote:

[snip]
> Do you really want DNS to contain tens of millions of RRs for unreachable hosts?

No, I really want people not to break network connectivity for tens of
millions of hosts for unreasonable reasons.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2001 14:39:18 -0600

Did I say people did it for security?

   Brian

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Feb 2001 17:48:18 +0700

Date:        Thu, 08 Feb 2001 14:39:18 -0600
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

This whole discussion has veered somewhere so far off into left field
that it has ceased to become relevant to anything.

There's no way the IETF (or ipngwg) is going to mandate two faced
DNS for anything - and only that would allow any ipngwg solution
which used two faced DNS to make site local addressing work, so
that simply isn't going to happen.

Beyond that it simply doesn't matter what sites decide, for good or
bad, reasons to do on their own networks, if they want to spend
lots, and increase maintenance problems, for no rational benefit that
I can find - there's no way I can stop them.   Nor do I care much.

But there's no way you are going to ever convince me to do such a
dumb thing...

But ...

  | Do you really want DNS to contain tens of millions of RRs for
  | unreachable hosts?

The short answer to that is "yes".

A slightly longer answer is that the DNS would already have all
that information if two-faced DNS is how the private namespace is
being managed (rather than NIS or something).   It is just that
some of it isn't being made visible to most of the world.  It is
still all there.   Having it there and visible makes no difference.
If I can't reach the host, I'm unlikely to be racing about looking
up its name either, so whether those tens of millions of hosts are
there & visible or not is going to be irrelevant to me, but they
are there anyway (but with more headaches for the site if the site
is using two faced DNS to "hide" them).

If you can really find a site that is running two faced DNS in
order to be nice to the rest of us by keeping the overall DNS size
smaller, then give them a plaque for effort, tell them while
appreciated, they're wasting their time, and to just let the rest
of us ignore their huge local DNS space, they don't need to hide it.

That is if you can find anyone doing it for that motive...

But can we possibly return to the more relevant question of just how
we are going to discover the site local address of a node which is
reachable that way, so it can be used...

And to give this message just a small amount of on-point content, I
don't think the method in Erik's draft will work as is, as - as was
pointed out before - it requires all nodes to know the method, and
I suspect we have already gone too far with v6 deployment for that.
We're already at the stage where only incremental changes can be
made now (that's a good thing!)

There are a couple of other minor problems as well, but compared
to that one, I don't think they matter.

So, I suggest that we keep all of the draft, except for the site
local addresses in the DNS (other than for isolated sites of course).
Instead, when a node has determined that its partner node is in the
same site (using the mechanisms from the draft), and if it implements
this method, and if it has not been configured (globally, or by the
application for this particular connection) to use only global addresses,
then have it send an ICMP "tell me your site local addresses" to the
partner node, and wait a short time (should be configurable, but let's
say bounded at 20ms to give an idea).   That packet it sends from its
own site-local address.   If it gets a response, and the response contains
any site local addresses, then it uses (one of) those addresses for
the connection (for the packet) (and caches the result for a while as well).
If it gets no response, or gets an ICMP "site local source exiting the site"
then it simply uses the global address.

Most often, what this will do is add one RTT to the startup time for
known local nodes, the first time that a connection is to be initiated
to the node (incoming connections don't do any of this, only when
initiating one, it would likely be done in the "translate name to address"
routines - just as Erik postulates).

The requirement for this to work, is that all nodes have global addresses,
if any nodes at the site do (ie: except for isolated sites, which would
simply stick their site-locals in the DNS).

Nothing at a connected site can have only a site local address (or there
would be nothing to find in the DNS in the first place).   [Aside: it
doesn't matter if the global address is found in a "private" DNS or the
regular global one].

A site local that is found in the DNS ought be treated just as if it was
a global address (for the purposes of connection establishment) - that
makes isolated sites work transparently (no need for any special config
to know if a site is isolated or not), and even allows people to site site
locals in their private DNS if they feel inclined.  Obviously the "tell me
your site local" address would never be used when starting with a site-local.

kre

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 15 Feb 2001 01:37:57 -0800

Just an attempt to summarize this thread:

Jim Bound thinks the use of site-local addresses is bad.

Robert Elz things that the use of site-local addresses is ok, but that
two-faced DNS is bad.

Other folks don't think two-faced DNS is so bad.  (I'm in this camp too...)

Robert Elz also made a good suggestion as to how hosts can learn the
site-local addresses of other hosts in the site (least-wise it seemed good
to me).  But the state of this suggestion is that it exists in an email and
nowhere else (i.e., no internet draft), so unless someone writes it up
nothing will happen to it?  (By the way Robert, are the ICMP "tell me your
site local addresses" and ICMP "site local source exiting the site" messages
you mention in your suggestion in existing drafts, or are these new messages
you are making up?)

In the absense of Robert's suggestion or Erik's draft
(draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to
existing implementations), I gather that there are only two possibilities:

1.  Don't use site-local addresses at all.
2.  Use site-local addresses and two-faced DNS.

Is this a reasonable summary?

PF

---

From: Robert Elz <[email-masked]>
Date: Fri, 16 Feb 2001 15:20:00 +0700

Date:        Thu, 15 Feb 2001 01:37:57 -0800
    From:        "Paul Francis" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Robert Elz also made a good suggestion as to how hosts can learn the
  | site-local addresses of other hosts in the site (least-wise it seemed good
  | to me).  But the state of this suggestion is that it exists in an email and
  | nowhere else (i.e., no internet draft),

Yes.

  | so unless someone writes it up nothing will happen to it?

I suspect that's true, and yes, it should get made into a draft.

  | (By the way Robert, are the ICMP "tell me your
  | site local addresses" and ICMP "site local source exiting the site" messages
  | you mention in your suggestion in existing drafts, or are these new messages
  | you are making up?)

The former is certainly new.  I thought that the latter existed already
(and may in the form of destination unreachable code 3), but this is
one which probably deserves an ICMP code of its own (that is: packet
attempting to exit limited scope").  The same thing would be used for
a link local source addr sent to a global address that is of link.

These kinds of packet errors can exist now (without actually provoking
them by suggesting they be used deliberately) can those who have
router implementations indicate what you're using to report the error
when you drop a packet because its source address would not be legal
on the outgoing link?   (code 2, "admin prohibited" is another possibility,
but to me that implies more of it being a local policy issue, rather
than a protocol violation).

In any case, any "that packet didn't make it" return would cause the
sending node to skip the site-local and try global.  If that also fails
then the host is just unreachable, whatever address is used.

  | In the absense of Robert's suggestion or Erik's draft
  | (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to
  | existing implementations),

Yes, the difference between the two is that mine only requires changes
to implementations that want to use site-local - so can be phased into
implementations over time.   Erik's requires that everyone understand
how to deal with site locals in the DNS before any are added.

  | I gather that there are only two possibilities:
  | 
  | 1.  Don't use site-local addresses at all.
  | 2.  Use site-local addresses and two-faced DNS.
  | 
  | Is this a reasonable summary?

I think so.   The first is a pretty simple outcome.   The second probably
means that only the larger sites, who can afford full time private DNS
maintainers (ie: not outsourcing their DNS to a public server) will be
able to use site-local - which is really the wrong outcome.  Site locals
are most needed by the smallest of sites which are most likely to renumber
(like: to use on your home net, in an environment when you get a different
global address every time you dial (or even just every month when you switch
to a cheaper, r less overloaded, provider)).

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 16 Feb 2001 00:49:10 -0800

At 3:20 PM +0700 2/16/01, Robert Elz wrote:
>  | (By the way Robert, are the ICMP "tell me your site local addresses"
>  | and ICMP "site local source exiting the site" messages
>  | you mention in your suggestion in existing drafts, or are these new
>  | messages you are making up?)
>
>attempting to exit limited scope").

Yes, we did add a code point to ICMP Destination Unreachable for
"beyond scope of source address" (Code 2).  However, just now when
I went to look for it, I discovered that the ICMPv6 update ID in which
that code point was added has timed out of the ID directory.  Ooops.

>(code 2, "admin prohibited" is another possibility,...

"admin prohibited" is Code 1.

Steve

---

From: Robert Elz <[email-masked]>
Date: Fri, 16 Feb 2001 16:48:04 +0700

Date:        Fri, 16 Feb 2001 00:49:10 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220810b6b297da6c10@[10.19.130.188]>

  | Yes, we did add a code point to ICMP Destination Unreachable for
  | "beyond scope of source address" (Code 2).

I thought I remembered that one...

  | >(code 2, "admin prohibited" is another possibility,...
  | "admin prohibited" is Code 1.

Oops yes - I read down to code three, and just assumed that the preceding
one would be 2, without checking properly...

kre

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 16 Feb 2001 14:15:03 +0100 (CET)

> 1.  Don't use site-local addresses at all.

with the exception that an isolated site (with no global addresses) can
use site-local addresses all it wants.

> Is this a reasonable summary?

I think so.

  Erik

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 16 Feb 2001 15:05:15 -0600

>   | you mention [...]?
> The former is certainly new.

No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt.

>  I thought that the latter existed already

I too thought "scope exceeded" existed, but I can't find it.

---

From: Robert Elz <[email-masked]>
Date: Sat, 17 Feb 2001 10:32:28 +0700

Date:        Fri, 16 Feb 2001 15:05:15 -0600
    From:        "Matt Crawford" <[email-masked]>
    Message-ID:  <[email-masked]>

  | > The former is certainly new.
  | No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt.

Ah yes, of course, I had forgotten the Node Addresses request was
in there along with names.   Good, that makes life simpler...

And apologies...

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 19 Feb 2001 14:37:59 +0900

>>>>> On Fri, 16 Feb 2001 15:05:15 -0600, 
>>>>> "Matt Crawford" <[email-masked]> said:

> No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt.

Is this really enough?  For example, I'm not sure if icmp-name-lookups
works in the following scenario:

Consider a mult-sited node A, that has 3 interfaces from I1 to I3.
I1 and I2 belong to a site X, and I3 belongs to another site Y.

 I1|   |I2  (site X)
   node A
     |I3    (site Y)

Let's assume that
- I1 has 1 global address (G). I2 has no site-local addresses.
- I2 has 1 site-local address (S2).  I2 has no global addresses.
- I3 has 1 site-local address (S3).  I3 has no global addresses.

Now, is it possible for a node B in the site X wants to know the node
A's site-local address(es) within the site X?

If B sends a type 3 node information query with the "A-flag" being set,
A will return both S2 and S3.  But B would not able to tell which one
belongs to the site X.

If B sends a type 3 node information query without the "A-flag" being
set and with the Subject Address being G, B will return no site-local
addresses.

If B sends a type 3 node information query without the "A-flag" being
set and with the Subject Address being S2, B will return S2 (and S2
only).  This result would be desirable, but is this really meaningful?

IMO, if we care about multi-sited nodes, the icmp-name-lookups spec
should be more scope-aware.  For example, we should add another bit
(or change the semantics of the A flag) so that the responder could
return all addresses of a given scope in the same scope of the Subject
Address.

					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, 19 Feb 2001 15:38:07 +0700

Date:        Mon, 19 Feb 2001 14:37:59 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | IMO, if we care about multi-sited nodes, the icmp-name-lookups spec
  | should be more scope-aware.

Yes, if we want to handle that scenario.   And it may be a good thing
to add that extra bit of generality anyway.

However, if, in your example, I1 had also had only site local addresses,
then this scheme could not work in the first place.   The assumption is
that all nodes have to have global addresses.  If we insist upon that,
we may as well also insist that all interfaces on all nodes have global
addresses (to be accurate here, this applies really only to nodes that
are to be the targets of a DNS initiated conversation - nodes that only
ever initiate connections, and never receive any, would not need global
addresses.   We should probably ignore that.)

If I2 has a global address (G2), then the node info request using G2
would find the site local (S2).   And it may be that that is the desired
result - if there's no site local corresponding to I1 (G) then someone
who wants to communicate with G (ie: I1) probably should be using the
global address (there had to be a reason I1 wasn't issued a site local addr
after all).

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Feb 2001 14:14:40 +0900

>>>>> On Mon, 19 Feb 2001 15:38:07 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> global address (there had to be a reason I1 wasn't issued a site local addr

Basically, I agree on all the points above, but I did not intend to
insist anything.  I just would like to point out that it's not so
trivial to use icmp-name-lookups as a protocol of "tell me your site
local addresses".  It is sometimes meaningless, and it sometimes does
not work...

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Feb 2001 14:14:40 +0900

JINMEI, Tatuya