[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility
Robin,
thanks for your review of Six/One Router! Your comments are very
useful. Replying to them one by one...
Slow DFZ handling of packets with option headers = header options
Would be interesting to find out how prevalent routers with slow-path
processing of IPv4 header options are in the DFZ. Here are two
suggestion on how to do without them:
(1) Use a new Six/One Router header, which looks to regular routers
like a transport header, instead of an IP header option. Make sure
that the Six/One Router header is never used in packets sent to non-
Six/One-Router-capable edge networks. Whether or not a remote edge
network supports Six/One Router can be found out via the mapping
resolution system (i.e., DNS Map, NERD, CONS, etc.).
(2) Do not use packet extensions at all, but use the source port and
source transit address of a packet as a key to the right mapping
information cached in a Six/One router. A Six/One router cache can be
initialized at the beginning of a new packet exchange by a separate
packet that the Six/One router at the originating edge network sends
to the Six/One router at the responding edge network. For this to
work, a source port has to be unique in combination with the source
transit address, so it may have to be translated. The port
translation would be transparent to hosts, however, because the
receiving Six/One router would reverse it.
I personally prefer the 1st approach because it does not rely on state
cached by Six/One routers. It thereby facilitates failover/handover
between Six/One routers.
OTOH, a benefit of the 2nd approach is that packets do not increase in
size when they enter transit space. But this is a marginal benefit
given that Six/One Router does not suffer path MTU problems anyway, as
explained further down in this email.
Maybe IPv6 option headers are not such a problem for DFZ
routers. Can anyone confirm this?
IPv6 Destination Options headers that are not used for source routing
are not looked at by routers. (Destination Options headers used for
source routing can, for this matter, be considered a different header
type with the same syntax as regular Destination Options headers.)
FWIW: Both of the aforementioned techniques to avoid IPv4 header
options could also be used for IPv6 packets, of course.
Packets are bigger with option headers
Right. But Six/One Router still avoids path MTU issues:
For packets sent from Six/One-Router-capable edge networks, all you
need to do is reduce the MTU locally in those edge networks. Consider
this a part of Six/One Router deployment.
For packets sent from legacy edge networks, no special treatment is
necessary because these packets are not enlarged along their path.
This is an advantage over Ivip or LISP proxies, which do enlarge
packets sent from legacy edge networks.
Modifying the DNS to give different results based on what
kind of network the requester is in (2.4)
Even if you knew the IP address of the requester, or the
IP address of its top level NAT if it was behind one or
more layers of NAT, you would need a really fancy
database to decide whether the requester was in an
upgraded network.
There is no need for a database about potential requesters in DNS
servers. But requesters must have a means to tell a DNS server when
they are interested in edge addresses instead of transit addresses.
Nevertheless, you are right that caching in DNS resolvers is a problem
in the current Six/One Router specification. I was actually going to
update the specification with the following alternative approach:
- Use separate DNS records for edge and transit addresses. Keep
transit addresses in A/AAAA records, and put edge addresses into, say,
A'/AAAA' records.
- Employ DNS proxies which, upon receiving or intercepting a DNS query
for A/AAAA records, (a) forward a query for A'/AAAA' records, and (b)
finally return the transit addresses from the retrieved A'/AAAA'
records within A/AAAA records. DNS proxy functionality would have to
be implemented in Six/One routers, and may in addition be implemented
in DNS servers inside Six/One-Router-capable edge networks. Six/One
routers use it to intercept DNS queries for A/AAAA records that are
about to leave their edge network. DNS servers inside Six/One-Router-
capable edge network use it when resolving domain names on behalf of
local hosts.
- A'/AAAA' records are syntactically identical to A/AAAA records.
Therefore, step (b) in the previous bullet is simply a replacement of
a record type number.
Deep packet inspection and modification
You are certainly right that address translation has problems when
done like NAT boxes do it today. But I believe that its use in Six/
One Router is acceptable for three reasons:
- The problems you describe are limited to *unilateral* address
translation. Six/One Router uses unilateral address translation only
for backwards compatibility. The problems go away once Six/One Router
is deployed on both sides of a packet exchange because address
translations are then limited to IP headers and get reversed before
packets reach the destination host.
- The problems with unilateral address translation (or unilateral use
of Six/One Router) are already prevalent today, due to the wide
deployment of NATs. Therefore, unilateral use of Six/One Router would
not make things worse in many situations.
- The introduction of IPv6 is likely to make NAT'ing more common
because IPv4/IPv6 interworking will depend on it [1,2]. I see Six/One
Router as a chance to avoid the problems of NAT'ing in those scenarios
where Six/One Router is deployed bilaterally.
[1] Iljitsch van Beijnum: Modified Network Address Translation -
Protocol Translation. Internet draft, November 2007.
[2] Brian Carpenter: Shimmed IPv4/IPv6 Address Network Translation
Interface (SHANTI). Internet draft, November 2007.
- Christian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg