Subject: RE: [saad] About saad

From: "Michel Py" <[email-masked]>
Date: Fri, 17 Oct 2003 09:53:48 -0700

Folks,

> James Kempf wrote:
> The DNS is a node identifier, but it currently can't be used by
> the transport layer as a connection endpoint identifier.

Nor by the network layer.

> Brian E Carpenter wrote:
> The reasons why FQDNs are imperfect EIDs have been listed quite
> recently (on one of the IPV6 lists I think).

Indeed. Besides, what we are talking about is scoping, and one of the
things that is totally in scope is to discuss at which layer(s) scoping
shall occur.

IMHO, scoping shall occur at the IP layer. The fact of the matter is (as
this discussion as shown) it seems that scoping is tied to the
identifier. I think that one of the sound discussions we should have is
to identify if indeed this is true. My vote is yes.

Now, _if_ the identifier is moved above the network layer, and if scope
is tied to the identifier as we might or might not decide it is, we
suddenly have a layer violation, because scope is going to be used at
the routing layer (the IP layer) and for the same reason routing must
not use DNS (because DNS needs routing) we will likely bump into the
issue that scope could not use {whatever the identifier in an upper
layer is} because of the same circular reference issue.

So, IMHO the beginning of the decision tree is:

     |
     v
     |
     /\
    /  \
   / Is \          +----------------------------+
  /scope \         | Since we don't have        |
 /  tied  \        | identifiers at another     |
/ to the   \  yes  | layer than IP now,         |
\identifier/--->---+ scoping is to be done      |
 \or not? /        | at the network layer.      |
  \      /         | if we ever get identifiers |
   \    /          | in other layers, situation |
    \  /           | will be revisited then.    |
     \/            +----------------------------+
     |
     v  no
     |
+----+----------+
| what are the  |
| reasons to    |
| move scope to |
| another layer |
| than IP?      |
+----+----------+
     |
     | ???
     |

Comments?

Michel.

_______________________________________________
Saad mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/saad

---

From: "James Kempf" <[email-masked]>
Date: Fri, 17 Oct 2003 10:03:01 -0700

One of the things I'd like to see is a list of why people use scoped
addresses (RFC 1918) in IPv4. Clearly, NATs are popular in IPv4 for reasons
other than lack of address space, and simply condemning them as evil or even
arguing against them without understanding why people want them isn't likely
to result in a usable technical solution, and probably won't persuade people
to stop using them anyway.

Given that list, one could then go through it and figure out what reasons
really do need to be dealt with at the network layer and what reasons could
more easily be dealt with at another layer. The result could be a kind of
list of requirements for a technical solution. The solution need not be a
new one, but it also could be.

I've never seen such an analysis done during the entire discussion on the
IPv6 list, though occasionally people do mention some reasons in email.

            jak

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Oct 2003 14:31:09 -0400

On Friday, October 17, 2003, at 01:03 PM, James Kempf wrote:
> addresses (RFC 1918) in IPv4.

I've talked to a very large number of people about this (or
rather why they use NATs, which is a slightly different
question), and the most common reasons are:

1) don't want to buy more addresses
2) simplification of network management/renumbering
3) security/firewalling/unreachability

The first two are already being dealt with in one form
or another.  The third is only peripherally being addressed
and certainly not satisfactorily (for whatever value of
"satisfactory").  The reality is that some large number
of users, including some users who consider themselves
relatively expert (network administrators, etc.) don't want
their hosts to be reachable by default but they do want
them to be able to initiate connections themselves.  I'm
not sure there's a good answer to this question, since
the users' wishes are incompatible with the IETF's working
assumptions about reachability.

There was a BOF on distributed firewalls several meetings
ago that I think is at least in some way relevant, but 1)
there doesn't seem to be a lot of momentum behind it, and 2)
some jiggering would be required.  Also, this really is a
big-A architecture problem that involves pulling together
some disparate technologies, and has been noted elsewhere,
the IETF doesn't do this sort of thing very well.

Melinda

---

From: "James Kempf" <[email-masked]>
Date: Fri, 17 Oct 2003 13:17:56 -0700

> assumptions about reachability.

But there are other ways that one could imagine doing this and still
maintain global routability only on the outbound connection.

For example, I've got a NAT at home on my 802.11/802.3/DSL access box. Now,
as a consumer, I don't have much choice in the matter: it's the only
technology out there that provides the functionality I want. And, it was
really easy to set up: plug it in, configure via a Web page, and it worked.
I suppose I could pay my DSL provider for more addresses, but I typically
just use one machine at a time (it might not be the same machine) but not
always and I don't leave it on all the time (due to electricity cost).

Suppose that, instead of a NAT, I could buy a box that had some number of
globally routable IP addresses preconfigured into it (and I could get more
by downloading them from the manufacturer via their Web page, maybe paying a
small fee). Suppose also there were some way for that box to communicate
with my service provider, without requiring a complex human intermediated
(and perhaps suits intermediated) business and technical conversation to set
up routing characteristics between the box and my ISP's network. The
communication would allow global routing outbound for purposes of initiating
a connection, but not inbound, and would be driven off my service profile
with the ISP (so that, for example, if I had a server, was paying more, and
needed the inbound connectivity, that would happen).

This would have no impact on the address architecture. The addressess on the
box could be globally routable, they could be HH IPv6 provider-independent
(if I'm using IPv6), but they need not be, since the manufacturer of the box
could apply to their local RIR for the address block like anybody else that
wants addresses. It would only require the routing reachability to be
configured properly, and in a way that is considerably more automated than
today.

                jak

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Oct 2003 18:03:26 -0400

On Friday, October 17, 2003, at 04:17 PM, James Kempf wrote:
> small fee).

This is not obviously going to work for v4 but I think is
one piece of a reasonably attractive approach.  Conflating
reachability and routing has caused some real problems.  But
when we look at stuff like VoIP applications it becomes
reasonably clear (at least to me, but obviously I'm biased)
that that sort of access device is still going to introduce
a heap of problems unless there's some sort of communication
with the host about what the host *really* wants (instead of
having the software on the access device make informed guesses).
Receiving end-to-end (i.e. unmediated signaling) telephone
calls is a good test case for whether or not these things can
work.

Melinda