Subject: RE: domain names as end-point identifiers?

From: "Michel Py" <[email-masked]>
Date: Tue, 16 Sep 2003 21:14:13 -0700

>> Michel Py wrote:
>> I will point out though that these issues are not limited to a system
>> where routers are rewriting packets and that it is likely going to be
>> easier to tackle them by containing the translation into a smaller
>> number of devices (routers) vs. doing the the id/loc mapping in each
and
>> every host.

> Keith Moore wrote:
> I have serious doubts about that; to me the boundary between API
> and host-to-network interface seems much cleaner and more definite
> than the boundary between one side of a router and another.

That's only half the picture; host people tend to like host solutions
and router people tend to like router solutions.

You missed that half of the picture with NAT: yes NAT sucks, it does not
change the fact that nowadays there are more NAT hosts than non-NAT
hosts. And you also missed that half of the picture by pissing so many
vendors about the NAT issue that made a point of not implementing 6to4
in their NAT  boxes just to piss you off in return, where having 6to4
implemented in NAT boxes would have been by far the best promotion
avenue for 6to4. Don't try to sell me that crap, I'm not buying it.

Anyway, you missed the point: Although there are things (such as NAT)
that eventually are worthy adopting the ideology-only "just say no" line
(if done right), you can't apply this to everything and in the case of
where the id/loc occurs we are looking more at a "whatever works"
situation.

Ideology is one thing, first try to overcome the handicap that id/loc
mapping at the host level will generate hundreds or thousands more
_times_ requests than on a router-based basis, two or three orders
magnitude more. Given what you have posted recently, I guess it's not
going to be DNS based. When you have solved the issue, come back and
argue the argument again.

Michel.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 08:58:34 -0400

> first try to overcome the handicap that id/loc
> magnitude more. 

Having the routers cache id-to-loc mappings is one thing; having them perform
id-to-loc mappings is something else entirely.  Yes, the hosts will still
generate such requests, but those requests don't have to traverse the entire
network if the local router knows what to do with them.  

But a lot is being assumed by the above statement.   I am fairly convinced
that id-to-loc mapping needs to be more like mobile-ip where you send a packet
to the id and get a redirect to the loc if the network can't route to the id,
than like DNS where you make an explicit query across the network and get
a response.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Sep 2003 22:02:21 +0200

On woensdag, sep 17, 2003, at 14:58 Europe/Amsterdam, Keith Moore wrote:

> Having the routers cache id-to-loc mappings is one thing; having them 
> perform id-to-loc mappings is something else entirely.  Yes, the hosts 
> will still generate such requests, but those requests don't have to 
> traverse the entire network if the local router knows what to do with 
> them.

You're making a host of assumptions here. One of them is that even 
though the info is requested per-host, it exists as per-site. This 
doesn't follow: it could very well be that each host has its own 
mapping, mostly independent from that of other hosts in the same site. 
This would probably be necessary in a mobility setup.

> But a lot is being assumed by the above statement.

Ah.  :-)

> I am fairly convinced that id-to-loc mapping needs to be more like 
> mobile-ip where you send a packet to the id and get a redirect to the 
> loc if the network can't route to the id,

But what if the network silently (or seemingly silently, re ICMP 
filtering) drops your packet?

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 16:40:02 -0400

> > Having the routers cache id-to-loc mappings is one thing; having
> > them perform id-to-loc mappings is something else entirely.  Yes,
> > the hosts will still generate such requests, but those requests
> > don't have to traverse the entire network if the local router knows
> > what to do with them.
> 
> though the info is requested per-host, it exists as per-site.

no, I'm not making that assumption.  the only assumption I'm making 
is that the mappings from id->loc are the same for every host, so that
they can be cached if they are used by multiple hosts.

> > mobile-ip where you send a packet to the id and get a redirect to
> > the loc if the network can't route to the id,
> 

if the network does that, it's broken.  we can design protocols to
tolerate transient failures; but we cannot design protocols that work no
matter what arbitrary filtering the network imposes.  the network has
a responsibility to make a best effort to deliver packets to their
destination intact.  this is nothing new.

(note that I never said that the protocol would use ICMP for signalling
such things.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Sep 2003 22:52:02 +0200

> they can be cached if they are used by multiple hosts.

Yes, that was what I was saying.

> if the network does that, it's broken.

Surprise: the network IS broken. Operators have turned to large scale 
ICMP filtering to be able to keep limping along during the recent worm 
season.

> we can design protocols to
> matter what arbitrary filtering the network imposes.

I agree in principle but in practice a protocol that depends on the 
random kindness of remote routers won't fly.

> the network has

Best effort may not be enough, not new either.

> (note that I never said that the protocol would use ICMP for signalling

Neither did I, I only cited ICMP filtering as an example. But ICMP is 
the protocol of choice for control messages.

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 16:59:49 -0400

> > we can design protocols to tolerate transient failures; but we
> > cannot design protocols that work  no matter what arbitrary
> > filtering the network imposes.
> 

Obviously IP will never work then.  I don't know why we've bothered with
it all these years, we must have been wasting our time.

I have no problem with trying to choose a signaling protocol that won't
look like an attractive target to ignorant sysadmins, or with trying
to pick a signalling protocol that is easy to distinguish from traffic
that sysadmins will be tempted to filter.  But vague assertions of the
form "sysadmins will filter X" are unsupportable.  If we pay them too
much heed we'll end up trying to design a protocol to meet an
unrealistic set of conditions, and either we'll never finish or we'll
put the robustness in the wrong place.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Sep 2003 00:28:43 +0200

On woensdag, sep 17, 2003, at 22:59 Europe/Amsterdam, Keith Moore wrote:

>> a protocol that depends on the random kindness of remote routers 
>> won't fly.

> that sysadmins will be tempted to filter.

That's only a tiny part of the problem.

Marcelo Bagnulo proposed a multi6 solution that was based on catching 
traffic that can't be forwarded. But we came to the conclusion that 
this won't fly because there is always the possibility that the last 
router in the path isn't aware of a failure situation. Now for 
nice-to-have functionality such as MTU optimization this shouldn't be a 
huge problem as you can fall back to some kind of conservative behavior 
when you don't get the desired feedback. For multihoming this is very 
different as the whole idea is to provide _better_ reachability. Having 
to depend on a router somehwere that isn't under the control of either 
endpoint to do something that routers often don't do today is asking 
for trouble. In a private network this _might_ possibly work. On the 
internet, it's useless.

> But vague assertions of the

Again, I agree in principle. But this can never be an excuse for lazy 
protocol design or implementation. Didn't we learn anything from the 
PMTUD disaster?

---

From: "Eugene M. Kim" <[email-masked]>
Date: Thu, 18 Sep 2003 11:53:08 -0700

IMHO it is more of a matter of who does what first.

If there is some existing and well-established practice among network
administrators that would not work with the new protocol, the protocol
has to be modified to avoid that.  However, if the protocol is first
established then deployed then later sysadmins do something that
interferes with the protocol, it is not the protocol designers' fault
but the sysadmins' fault that broke existing protocols.  (Chances are,
in fact, that if the new protocol is found to be useful among users and
widely deployed, sysadmins probably wouldn't want to take steps that
break the protocol.)

If there were two alternatives, one of which works even with some
pessimistic foresights about what sysadmins *might* do in the future and
the other doesn't, but both being similar or same in their
functionality, it would do make a total sense that we must choose the
former.  However, if there is only one alternative, we should not reject
it but opt for it at least tentatively until a better alternative comes
forward.

Regards,
Eugene