[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