On Jul 2, 2009, at 12:41 AM, Patrick Frejborg wrote:
Hi Christian,
trying to come up with more arguments and here is an early simple
idea, more or less a brain dump that you (all of you) should try to
shoot down.
NAPT devices have to keep track of both IP addresses and ports, the
binding can become quite complex. But if the connection also have host
identifiers in the header of the datagrams the NAPT box doesn't need
to keep track of the ports - the connection can be tracked with the
help of the host identifier.
Not so interesting but it gets better if the host identifier is added
to the DNS record. By adding a host identifier to the DNS record the
NAPT box could accept traffic from the Internet and redirect it to the
correct host in the private network. This can be achieved by having
the DNS entry as the IP address with the public IP address of the NAPT
box and the host identifier with the global unique identifier of the
internal server. Then you create a static binding at the middlebox - a
host identifier is binded to the internal IP address of the server.
Now the middlebox can handle both inbound and outbound connections,
with one public PA IP address, and still provide end-to-end visibility
in case you need to troubleshoot sessions. Also the meaning of DNS
changes slightly, a DNS look up tells us today "what is the local IP
address of the server". With the host identifier added the DNS look up
would tell us "via this attachment point at the border of Internet the
internal host can be reached".
Patte,
Just FYI: your above description actually matches to an existing
implementation pretty closely: Apple's Mobile.Me/BTMM (Back To My Mac).
I gave a short talk on this implementation back in February at the
Dagstuhl Seminar on naming and addressing:
"What to Use as Host Identifier: there is theory, and there is
practice"
http://www.dagstuhl.de/Materials/Files/09/09102/09102.ZhangLixia1.Slides1.pdf
- This is really Apple/Stuart Cheshire's work; I failed to get Stuart to
attend the seminar, so I gave the talk.
- I wanted to make this work known to the community because it
represents a
*very* pragmatic way of adding the identifier into the pictur--it is
running today (the claim is that BTMM got millions of users)
It may be far from perfect (I've been collecting a list of things that
need to be improved), but seems to me a good/pragmatic starting point.
How then to achieve multi-homing?
I'd like to clarify a bit here: there are multiple levels of
multihoming, for example,
- site multihoming: UCLA is multihomed to multiple providers
- host multihoming: an iphone has multiple interfaces that even
goes to different providers.
(of course there is also subnet multihoming, handled by IGP routing).
this naturally leads to the question of whether one would attempt one
solution for all levels of multihoming, or have a separate solution
for host multihoming, and handle site multihoming in a different way.
If this is really doable the outcome is that PI-addresses are no
longer attractive, you can publish services towards Internet with your
internal addressing scheme - the routing architecture of an
organization is an internal affair and Internet doesn't need to know
about how it is constructed. But still external customers, partners
etc. can reach your published services with the help of the host
identifier.
this can be one possibility, but not the only one.
There are people out that who want PI blocks, or want to hold on their
PI blocks.
It is because PI blocks make some part of their jobs easier.
It is not because there is something that can be theoretically proven
impossible without PI blocks (even the need for identifier can't be
proven this way). As I mentioned in an earlier reply, networking (both
designs and operations) is about making a best engineering tradeoffs
(and the criteria for "best" vary for different parties).
Isn't networking fun? :-)
Lixia
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
