Subject: Re: [RRG] Re: Six/One Router revised 2008-07-12 - IPsec

From: Robin Whittle <[email-masked]>
Date: Fri, 08 Aug 2008 02:24:14 +1000

Short version:   Like my Ivip6 proposal, I think that Six/One Router
                 requires the redefinition of the current Flow Label
                 bits to be used for another purpose.

                 Hosts would need to ignore the current "Flow Label"
                 bits when scrutinising the original packet in
                 ICMPv6 Error Messages, including Packet Too Big
                 messages, since the Translation Routers may
                 change at least one bit there.  (This applies
                 to my Ivip6 proposal too - maybe some minor
                 tweaks to host stacks would be required.)

                 I can't see how Six/One Router's Unilateral mode
                 could support IPsec authentication of the IPv6
                 header.

Hi Christian,

Thanks for this:

> Wow!  Thanks a lot, Robin, for this thorough review of Six/One Router!

I was looking for problems, but it goes without saying that I think
that the prospect of doing translation - or anything else - which
doesn't involve encapsulation has so many benefits that we should
pursue these options with vigour.

> This is by far the most careful review I have ever gotten on a paper
> -- longer than the paper itself. ;-)   Please give me some time to
> respond to your questions.  Will do so ASAP.

I am sure it is not longer, and it only took a fraction of the time
and effort you put into writing your paper and devising this second
version of Six/One Router.

One thing your current proposal requires is the use of a bit in the
IPv6 header:

http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

Page 6:  This paper suggests reserving a bit in the IP header,
         henceforth called the Bilateral/Unilateral bit, to
         distinguish the mode in this case. (3)

         (3) An alternative to reserving a bit in the IP header is

             to specify an extension header that identifies the mode
             in which packets are exchanged.

An extension header would remove probably the greatest attraction of
Six/One Router - no extra packet length.  So I think you really need
a bit from the header.  The only place I think that could come from
is the Flow Label.

So in order for Six/One Router to be deployed (without extension
headers) I think you would need to have the Flow Label bits
redefined to provide a place for your Bilateral/Unilateral bit.
Hosts would need to not rely on the current Flow Label bits being
unaltered in the network.

The core routers (other than the translation routers) would not need
to be changed.

In order for PMTUD to work in the translated part of the path, and
for all the other ICMPv6 Error Messages (RFC 1885) to work in that
part of the path, the sending host would need to ignore the state of
your Bilateral/Unilateral bit in the copy of the offending packet
which is enclosed in the ICMPv6 Error Message.

Hosts should be very fussy about accepting ICMPv6 Error Messages, to
protect against an off-path attacker guessing the values of packets
recently sent and thereby successfully launching a DoS by sending
spoofed ICMPv6 Error Message packets to the sending host.

There are no specific details in RFC 1885 or in the PMTUD RFC 1981
about how fussy hosts should be before accepting an ICMPv6 Error
Message.

I think this is probably quite feasible.  In the longish timeframe
we have for deploying a scalable routing solution for IPv6, I think
there would be time to tweak host stacks to make them ignore the
current "Flow Label" bits when checking ICMP Error Messages.

My new "Label Forwarding" proposal (Ivip6) was prompted by looking
into the IPv6 header for a place for your bit - and finding the Flow
Label the only likely place to grab a bit from.

My proposal uses the entire 20 bit Flow Label for another purpose.
So like your proposal, I need to argue why we don't need the Flow
Label in the future, and why it is worth putting these bits to a
better purpose.  The ITRs and ETRs of my proposal - and the
translation routers of yours - obviously need to do new things with
the old "Flow Label" bits.  With your proposal, the existing core
routers should be fine - since they currently pass on and otherwise
ignore the Flow Label bits.

However, for my proposal to work, most of the core routers need to
be upgraded to have new forwarding behaviour, based on the state of
these 20 bits.  So your proposal has a bunch of hurdles, and mine
has one extra large hurdle in this regard.

Still, being able to do a scalable routing system for IPv6 without
encapsulation would be an enormous advantage over map-encap
approaches - so I think there are strong reasons for convincing
everyone these hurdles should be jumped.

I will write some more another time about why I think the Flow Label
is of very limited value indeed.

In my critique, I questioned whether it was OK to simply adjust 16
bits of the address you are rewriting to keep the checksums the
same.  This is discussed on the right of page 7 of your paper.

    This technique is applicable to all packets, even if their
    payloads are integrity-protected or encrypted. It is
    also efficient because the checksum does not have to be
    localized within a packet. Mapping edge and transit
    addresses such that the checksum does not change during
    address rewriting is practical where the routing prefixes
    of IPv6 edge and transit addresses are at most 48 bits long:
    The remaining 16 or more bits in the standard 64-bit subnet
    prefix of an IPv6 address can then be used to compensate for
    the checksum difference that rewriting of the routing prefixes
    alone would create.

I am not used to the "0 = MSB" way of talking about bit numbers.
Using ordinary 127 = MSB terminology, I wrote that you would need to
alter bits 64 to 79 (63 to 48 in network byte order) to do what you
propose, according to how you changed bits 80 to 127 (0 to 47) in
the rewriting operation.  Here is a diagram which avoids bit
numbers.  It is in hex with MSB on the left.

    MSB                                 LSB

    xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz

z bits are unaffected by address translation.

My understanding is that you want to rewrite all of x and y bits,
but you think that in order to keep the checksum the same.  So the
best approach is to rewrite the most important (most significant)
bits the way you want, and not try to be specific about the yyyy 16
bits, because you are going to have to set them to some value based
on the other changes (difference between the 16 bit sum of the
original xxxx xxxx xxxx bits and the 16 bit sum of their translated
values) to keep the 16 bit checksum from changing.

This therefore would limit the use of your system to prefixes of /48
or shorter - which is not much of a problem, I think.

This all sounds very messy.  I could imagine it working, but I think
there might be some nasty gotchas in there somewhere.

The IPv6 header itself has no checksum, but the UDP and TCP headers
have 16 bit checksums, which include the header.  So far, so good -
adjusting those 16 yyyy bits should do the trick.  I assume these
checksums are important to each core router in the translated part
of the path, because the routers will drop a packet with a bad checksum.

However, I can't see how Six/One Router could work in certain
scenarios and still support IPsec header authentication.

In Figure 2 (Bilateral), there is no problem, because the
destination host gets a packet which is identical to that sent by
the sending host.

However, in:

  Figure 4: (Unilateral) Backwards compatibility for packet
            exchanges between upgraded and legacy edge networks

and

  Figure 5: Packet exchange in Unilateral mode between
            upgraded edge networks

the received packet has different addresses from those in the packet
which was sent.

My understanding of the RFC 4302 3.3.3.1.2 is that the source and
destination addresses are included in what is checked by IPsec.
(The Flow Label, thankfully, is not.)

This is a new critique:  as far as I know, the way IPsec processes
these items in the header is not a simple 16 bit checksum.  I
understand there are multiple possible "integrity check" methods
which can be used.  These advanced hash algorithms do not simply
work would with 16 bit checksums on their input material.

  http://en.wikipedia.org/wiki/Ipsec

    Transport mode

       In transport mode, only the payload (the data you transfer)
       of the IP packet is encrypted and/or authenticated. The
       routing is intact, since the IP header is neither modified
       nor encrypted; however, when the authentication header is
       used, the IP addresses cannot be translated, as this will
                 ---------------------------------

       invalidate the hash value. The transport and application
       layers are always secured by hash, so they cannot be modified
       in any way (for example by translating the port numbers).
       Transport mode is used for host-to-host communications.

The way to get around this for ordinary NAT is to encapsulate the
whole packet in IP and UDP headers:

  http://en.wikipedia.org/wiki/NAT-T
  http://tools.ietf.org/html/rfc3948

but doing that would cancel the primary attraction (I think) of
Six/One Router over map-encap: the fact that the packet does not get
any longer.

I haven't looked at all this in detail, but my impression is that
Six/One Router, except in the Figure 2: mode (Bilateral - between
two upgraded networks) would be incompatible with IPsec.

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Christian Vogt <[email-masked]>
Date: Thu, 7 Aug 2008 20:50:12 +0300

>                 bits to be used for another purpose.

Hi Robin,

thanks for sharing this idea.  You are suggesting that the Bilateral/
Unilateral bit [*], which Six/One Router requires, could be taken from
the IPv6 Flow Label field.  This would be possible, right.

I was myself considering taking the bit from the Traffic Class field.
This would have two advantages:

- Some bits in this fields are still unused.

- Backwards compatibility:  The IPv6 spec states that bits from the
   Traffic Class field can be set by routers, and that hosts and
   routers must ignore bits they do not recognize.  Consequently,
   nothing would break if one of the bits were allocated for use by
   Six/One routers.

Think it makes sense?

Regarding your proposal, Robin, for flow-label-based forwarding:  A
circumstance that mitigates the disruptive impact of re-defining the
Flow Label field is that (i) use of the Flow Label field is currently
pretty rare, and that (ii) hosts not using a flow label must ignore
the field [RFC 3697] anyway.

- Christian

[*] Background info for other folks on this list:  The Bilateral/
Unilateral bit is used by Six/One routers to determine, in stateless
fashion, the mode of a packet received from the Internet core.

---

From: Christian Vogt <[email-masked]>
Date: Thu, 7 Aug 2008 21:14:39 +0300

Robin -

> My understanding is that you want to rewrite all of x and y bits, but
> you think that in order to keep the checksum the same.  So the best
> approach is to rewrite the most important (most significant) bits the
> way you want, and not try to be specific about the yyyy 16 bits,
> because you are going to have to set them to some value based on the
> other changes (difference between the 16 bit sum of the original xxxx
> xxxx xxxx bits and the 16 bit sum of their translated values) to keep
> the 16 bit checksum from changing.
>

No, not at all.  You can continue to use the y-bits in the address as
usual.  (These bits are called "subnet ID" in RFC 4291 terminology.)

The subnet ID simply changes by a constant offset as a packet
traverses a Six/One router.  (And FWIW, this constant is the same for
all packets that a given Six/One router forwards.)  The reason why the
subnet ID doesn't lose its meaning is that it is used only within an
edge network, and packets always have the original (unchanged) subnet
ID while within a given edge network.

Of course, the proposed method is just one example of how checksum
changes could be avoided.  Others are possible -- like re-computing
the checksum, or obtaining transit routing prefixes that are
checksum-equivalent with the corresponding edge routing prefix.  (A
"routing prefix" is what RFC 4291 calls the x-bits in the address.)
Since the method is transparent to the remote peer, a Six/One router
can do whatever it likes as long as the checksum in the indirected
packet is consistent with the packet.

And worthwhile to emphasize, you only need any of these methods for
backwards compatibility, not for packet exchanges between upgraded
edge networks.

Does this makes things clearer?

Cheers,
- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 7 Aug 2008 21:32:44 +0300

Robin -

>                 could support IPsec authentication of the IPv6

You are correct.  In backwards compatibility mode, Six/One Router
breaks IPsec Authentication Header.  It's the same as with NATs.
Packet exchanges between two upgraded edge networks don't have this
limitation.  And packet exchanges in IPsec ESP don't have it either.
But packet exchanges in IPsec AH with legacy edge networks do.  One
may argue that this is acceptable because IPsec AH is not widely used,
but that is clearly a personal opinion.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2008 16:45:29 +1200

> - Some bits in this fields are still unused. 

Not true, unfortunately. They are all allocated to either ECN
or diffserv. These are both encoded fields, so there are no spare
bits.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Fri, 08 Aug 2008 18:36:37 +1000

Short version:   Further discussion of the Flow Label as the only
                 available place to snaffle a header bit for the
                 Bilateral / Unilateral bit.

                 Diagrams depicting the actions of Bilateral
                 and Unilateral translation shown in Figs 2, 4
                 and 5.

                 The awkwardness of rotating 16 bits of the
                 address during translation to avoid the need
                 to change the checksum which covers the address.
                 This seems to limit the granularity of the
                 system to /48.  Ivip6 goes to /64.

                 The awkwardness of choosing Transit prefixes
                 for each End user prefix such that translation
                 will not affect the checksum.

                 The awkwardness of doing neither, but of updating
                 the checksum instead.

                 Unilateral translation breaks IPsec AH.  This is
                 not just during transition until all hosts are
                 using the new kind of address space.  It will
                 affect communications with all hosts which never
                 change to the new style of address space - and if
                 people are happy having their hosts on their ISP's
                 conventional PA address space, why should they
                 have to change to the new Six/One Router kind of
                 space?

Hi Christian,

Thanks for your replies, in which you wrote:

> You are suggesting that the Bilateral/ Unilateral bit, which
> Six/One Router requires, could be taken from the IPv6 Flow
> Label field.  This would be possible, right.
>
> I was myself considering taking the bit from the Traffic Class
> field.  This would have two advantages:
>

OK - I will return to this.

> - Backwards compatibility:  The IPv6 spec states that bits from
>   the Traffic Class field can be set by routers, and that hosts
>   and routers must ignore bits they do not recognize.
>
>   Consequently, nothing would break if one of the bits were
>   allocated for use by Six/One routers.
>
> Think it makes sense?

In principle.  I assumed all 8 bits in the Traffic Class octet were
used - here is my detailed investigation.

> or diffserv. These are both encoded fields, so there are no spare

FWITW, here is my research:

<research>

    RFC 3168 (2001-09) states that in both IPv4 and IPv6, the two
    ECN bits (6 and 7) are used - with all four codepoints.  Section
    22 has a history of this octet.

    RFC 2474 (1998-12) and RFC 2780 (2000-03) specifies bits 0 to 5
    are for DiffServ (Differential Services Field - DSCP = DiffServ
    Code Point) with bits 6 and 7 unused.  However, this was before
    RFC 3168.

    RFC 2474 apparently allows routers to change these 8 bits.  From
    RFC 3168:

       Prior to RFC 2474, routers were not permitted to modify
       bits in either the DSCP or ECN field of packets
       forwarded through them . . .

    So bits 7 and 8 are tied up with Explicit Congestion
    Notification.  What about the DiffServ bits?

      http://tools.ietf.org/html/rfc2474#section-6

        012345
        xxxxx0   Pool 1    For codepoints recommended in standards.

        xxxx11   Pool 2    Experimental / Local use.

        xxxx01   Pool 3    Initially available for experimental /
                           Local use - but which should be
                           preferentially utilized for standardized
                           assignments if Pool 1 is ever exhausted.

    Counting in network byte/bit order (backwards binary) RFC 2474
    defines 000000   Default Per Hop Behavior (PHB)

        100000   } Class Selector PHBs.
        010000   }
        110000   }
        001000   }
        101000   }
        011000   }
        111000   }

    RFC 2597 specifies 12 of the 32 Pool 1 codepoints, using all
    five available bits.

      http://tools.ietf.org/html/rfc2597#section-6
      Assured Forwarding Per Hop Behavior codepoints:

        100100
        010100
        001100
        011100

        100010
        010010
        001010
        011010

        100110
        010110
        001110
        011110

    RFC 3246 specifies another codepoint:

        101110  Expedited Forwarding PHB

    I may have missed some, but that is 21 of the 32 codepoints in
    bits 0 to 4 taken. 	

</research>

I think the only way you could get a bit here for the Six/One Router
Bilateral/Unilateral bit is either to:

  1 - Redefine the "Flow Label" so you can use one bit of this.

  2 - Have DiffServ redefined (for IPv6 at least) not to use bit 5,
      so there are no pools 1 or 2.  Then use this bit 5.

      (This might require router changes, so they treat all values
       nnnnn1 the same as nnnnn0.)

Alternatively, I think you could:

  3 - Decide that Six/One Router won't support DiffServ fully or
      perhaps at all.  For instance, the DiffServ RFCs remain, but
      DiffServ wouldn't be able to be used as is over Six/One
      router, due to problems such as:

      a - After the first translation router, the packet having a
          different bit 5 state - unless all core routers were
          upgraded to ignore it.  Still, this would wrap pool 2 and
          3 values to pool 1 values - unless the first translation
          router converted all values zzzzz1 to 0000B, where
          B is the Bilateral/Unilateral bit.

      b - After the recipient translation router, the packet having
          bit 5 changed from the state it was set by the sending
          host or routers prior to the first translation router.

Sending host's can't tell - and shouldn't have to worry about -
whether the destination host is reached via Six/One Router - and
since Six/One Router is supposed to carry traffic for most end-user
networks, any limitation you place on DiffServ will become a
limitation for all uses of DiffServ for any communication which
crosses the inter-domain core.

As far as I can see, you need to have the "Flow Label" redefined if
you need an extra bit in the header.

> Regarding your proposal, Robin, for flow-label-based forwarding:
> A circumstance that mitigates the disruptive impact of re-defining
> the Flow Label field is that (i) use of the Flow Label field is
> currently pretty rare, and that (ii) hosts not using a flow label
> must ignore the field [RFC 3697] anyway.

Yes.  I think that it would be possible for the IETF to agree to
redefine the function of the Flow Label bits if it was crucial to
the best scalable routing solution.

Stepping back a little, I don't clearly understand the reason for
needing this "Unilateral/Bilateral" bit, since I don't clearly
understand the need for Unilateral mode between two hosts, both in
upgraded edge networks.  (Section 2.4.2 and Fig 5.)

Why don't you simply make it a rule that (referring to Fig 5) if the
host on the left (ABC:A) sends a packet to the host on the right
(DEF:B) that it always makes the destination address equal to DEF:B?

In other words, why don't you insist that upgraded hosts never send
packets to transit addresses - only to end-user addresses?

Perhaps this is because you want to have the one end-user address
and one or more transit addresses in the DNS AAAA record, and it is
possible that ABC:A will try to use these in some arbitrary order,
and find that the first one it tries works, with the first one
happening to be a transit address.

My understanding of the need for putting transit addresses, such as
 (taken from the example below):

  2001 0200 0400 29FF 1111 2222 3333 4444  Transit address for:
  4000 0000 1000 0000 1111 2222 3333 4444  End-user network address.

in the AAAA records is so that when a host in a non-upgraded network
tries to contact the destination host, identifying it by its FQDN,
it will try these addresses and try again if one doesn't work.

The second one won't work, because it is not in an advertised
prefix.  So it tries the first one, which is the transit address,
which works.

So perhaps you could create some way that hosts in upgraded networks
only get DNS results with the end-user network address, or that they
can easily identify which of multiple IP addresses is the end-user
one.  Then maybe you wouldn't need Unilateral mode between two
upgraded networks?

One way of doing this might be to say that all end-user address
space in the new Six/One Router style of end-user network comes from
the prefix 4::/3 - or some other simple prefix.  Then - and you need
upgraded host operating systems to do this - the host can know from
its own address it is an upgraded network and see from the various
addresses in an AAAA record which is also an end-user address, since
all the transit addresses will not be within 4::/3.

I think that for IPv6 scalable routing, modest upgrades to hosts and
routers should be considered - if they lead to a significant
long-term reduction in overhead and/or complexity.

Returning to this Bilateral/Unilateral business, I still find it
confusing.

Here is my summary of the three diagrams.  The host on the left is
always in an upgraded network.  For Fig 2 and 5 the right one is in
an upgraded network too.

  X = translated.

  T = Transit address of a host in a Six/One Router user network.

  E = Real address of a host in a Six/One Router user network.

  N = Real address of host in ordinary network.

  U/B = Unilateral / Bilateral bit state.

Fig 2 Bilateral  Both networks upgraded

 L --> R    Src  X           Src  X
            Dest X           Dest X

 Src:   E             T               E
 Dest:  E             T               E
                      B

            Src  X           Src  X        L <-- R
            Dest X           Dest X

 Src:   E             T               E
 Dest:  E             T               E
                      B

Fig 5 Unilateral  Both networks upgraded

 L --> R    Src  X           Src
            Dest             Dest X

 Src:   E             T               T
 Dest:  T             T               E
                      U

            Src              Src  X        L <-- R
            Dest X           Dest

 Src:   T             T               E
 Dest:  E             T               T
                      U

Fig 4 Unilateral  Right host not in upgraded network

 L --> R    Src  X
            Dest

 Src:   E             T
 Dest:  N             N
                      U

            Src                             L <-- R
            Dest X

 Src:   N             N               N
 Dest:  E             T               T
                      ?

In all three examples, when the left translation router receives the
packet from its left host, how does it know whether or not to do
Bilateral or Unilateral translation?

If it can figure this out - presumably from what it knows about the
address space and which prefixes are Transit or End user prefixes,
then why do you need a flag bit in the packet sent to the right
translation router?  Can't both the left and right routers in Fig 2
and Fig 5 figure out the Transit or End nature of the source and
destination addresses they receive, and then whether or not to
translate, if necessary, to both Transit or both End user, depending
on whether the packet is going to the core or to an Edge network?

The state of the Unilateral/Bilateral bit would need always to be B
when raw packets (having not been through any translation router)
arrive at the left translation router in Fig 4.

I am still not sure I understand your proposal fully.

>> My understanding is that you want to rewrite all of x and
>> y bits, but you think that in order to keep the checksum the
>> same.  So the best approach is to rewrite the most important
>> (most significant) bits the way you want, and not try to be
>> specific about the yyyy 16 bits, because you are going to have
>> to set them to some value based on the other changes
>> (difference between the 16 bit sum of the original xxxx
>> xxxx xxxx bits and the 16 bit sum of their translated values)
>> to keep the 16 bit checksum from changing.
>>
>> This therefore would limit the use of your system to prefixes of
>> /48 or shorter - which is not much of a problem, I think.
>
> No, not at all.  You can continue to use the y-bits in the address
> as usual.  (These bits are called "subnet ID" in RFC 4291
> terminology.)

> (A "routing prefix" is what RFC 4291 calls the x-bits in the
> address.)

> traverses a Six/One router.  (And FWIW, this constant is the same
> for all packets that a given Six/One router forwards.)

I don't understand how this can be the case.  The offset is only
constant for a particular pair or Transit and End user addresses.

Let's say an End-user prefix 4000:0000:1000::/48 uses a provider
prefix 2001:0200:0400::/48 as its Transit prefix, then when the
translation router receives a packet from an End-user in its network
and the source address is:

   xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz
   4000 0000 1000 0000 1111 2222 3333 4444

it needs to translate it to a Transit prefix (no matter whether this
is Unilateral or Bilateral) The result, ideally, would be:

   xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz
   2001 0200 0400 0000 1111 2222 3333 4444

However, to keep the 16 bit checksum the same, you would need to
make the yyyy bits equal to:

yyyy + (4000 + 0000 + 1000)
     - (2001 + 0200 + 0400)  =  yyyy + 29FF

So within this /48 prefix, there is a rotated translation between
the yyyy bits of all host's addresses in the End-user network and
the address from which they appear to use as Transit addresses.  For
the recipient host on the right, in Figure 4 (Unilateral translation
for supporting hosts in non-upgraded networks) this is the address
it must use to send packets to or receive packets from the host on
the left.

Assuming the upgraded network on the left is multihomed, translating
for a second provider prefix would result in a different rotation value.

Translating back to the original address at the recipient Six/One
Router, you need to ignore the yyyy bits for a moment and translate
the xxxx xxxx xxxx bits back to their value for the appropriate
end-user network, and then (for the above example) subtract 29FF
from the yyyy bits.

This would not be possible if your end-user network had a prefix
length of /49 or more.

So I think it limits the granularity of the system to /48 - as long
as you use this technique of avoiding changing the checksum.  That
is probably fine, but for Ivip6, I want the granularity to be /64.

Recent RRG rough consensus is for a mapping granularity (and
therefore the granularity with which EID prefixes AKA micronets can
be defined) of one IP address: for IPv6: a /128.  Or at least that
is my interpretation of:

  http://psg.com/lists/rrg/2008/msg01299.html

    for the mapping function, we have consensus that we should
    support host specific identifiers, as well as blocks.

I think /64 is a much better granularity for IPv6 than /128.

> The reason why the subnet ID doesn't lose its meaning is that it
> is used only within an edge network, and packets always have the
> original (unchanged) subnet ID while within a given edge network.

I understand that there are no translations within any given edge
network.

I wasn't suggesting the rotation of the yyyy range (subnet ID) would
 not work - just observing that it is a messy arrangement having a
given end-user host appear at transit addresses with differing yyyy
values for every one of the transit prefixes it uses (such as with
multihoming).

In Fig 4 - Unilateral writing to make a user network host reachable
from a host in a non-upgraded network, via a transit address - the
non-upgraded host would be able to send a packet to:

  xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz
  2001 0200 0400 29FF 1111 2222 3333 4444

and the translation router would look at the xxxx xxxx xxxx bits, do
the translation, subtract 29FF from yyyy and so cause the packet to
be addressed to the proper end-user network host:

  xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz
  4000 0000 1000 0000 1111 2222 3333 4444

The non-upgraded host could have gained this 2001.... address either
by being sent a packet by the host in the end-user network, by
finding it was an address which worked, out of several in an AAAA
record from a DNS lookup, or by being told the address by some other
means.

I am not saying it can't be done, just that having the transit
addresses being more than a simple translation is a confusing aspect
of this arrangement.  One can't just overwrite bits, one must look
at what the bits were beforehand, and then do some hex arithmetic on
the difference, and add or subtract that from the yyyy bits.  This
would need to be done, for instance, to generate entries in the DNS
AAAA record.

> changes could be avoided.  Others are possible -- like
> re-computing the checksum, or obtaining transit routing prefixes
> that are checksum-equivalent with the corresponding edge routing
> prefix.

I will return to this second point below.

My understanding of "recomputing the checksum" is that you would
need to find and change the checksum for the whole packet, which is
not in the IPv6 header, but which may be in whatever follows:

          Use IPv6 Pseudoheader?
          | http://tools.ietf.org/html/rfc2460#section-8.1
          |
Protocol  |     Checksum location or notes
       |  |     |

     TCP  Y     Bits 128 to 143.

     UDP  Y     Bits 48 to 63.

    SCTP  N     32 bit "checksum" - but I don't see any
                reference to the IP header.

    DCCP  N     Doesn't seem to refer to IP header.

    ICMP  Y     Bits 16 to 31.

    IGMP  N     Checksum is only for the IGMP payload.

But for those packets with checksums, you also need to step past any
extension headers.

This sounds really tricky and expensive to do on every translation.
 Map-encap involves extra bytes in the header, but at least it
delivers the desired packet verbatim, without the need for any of
this translation and checksum work.

> obtaining transit routing prefixes that are checksum-equivalent
> with the corresponding edge routing prefix.

I think this would be highly restrictive.  For a given end-user
prefix - for example any particular /48 - you have to choose a
provider prefix:

    aaaa bbbb cccc /48

However, to make this choice result in no change being required to
the yyyy bits in order to keep the checksum value unchanged, then
for any particular combination of values aaaa and bbbb, you can't
choose any value cccc - there is only one of the 64k values of cccc
which can be chosen.

> Since the method is transparent to the remote peer, a Six/One
> router can do whatever it likes as long as the checksum in the
> indirected packet is consistent with the packet.
>
> And worthwhile to emphasize, you only need any of these methods
> for backwards compatibility, not for packet exchanges between
> upgraded edge networks.
>

Yes.  "Only for backwards compatibility" is no small thing, because
this is the condition imposed on virtually all communications for
early adopters - and if these restrictions are unpalatable, then
there will only ever be a few adoptors.  Then, the system would
never be widely enough adopted either to make a difference to the
routing scaling problem or to enable the adoptors to reap the
benefits by enjoying more traffic which is free of the "backwards
compatibility" restrictions.

Also, isn't there a continuing role for end-users being on ordinary
PI addresses, which are not subject to translation?  If so, then
there will always be lots of space used which has no translation
router in its network.

> but that is clearly a personal opinion.

OK - but what about my previous point that not all end-users might
be on the new kind of address space?

With map-encap such as LISP with PTRs or Ivip4 with OITRDs, or with
Ivip6's "Label Forwarding" approach (also with OITRDs) it is fine
for there to be plenty of end-users on conventional PI space.  They
can communicate fine with the new kinds of end-user networks - hosts
on ordinary PI addresses would need to have their packets go through
an ITR in order for the packet to reach the EID destination host
(LISP) or the micronet addressed destination hot (Ivip).  That ITR
could be in the ISP network of the PI sending host, or if that ISP
for some reason had no ITRs (ISPs should provide them) then the
packets will find their way to the core, where they will go to the
nearest OITRD (PTR for LISP) and then be tunneled to the ETR.

So there is no loss of connectivity between hosts on ordinary
address space and on the new kind of address space, irrespective of
whether there are ITRs or not in the network of the sending host
which is on a conventional address.  IPsec will work fine.
(Assuming there is no NAT at either end.)

With Six/One Router, the inability for IPsec AH to work is a
permanent restriction on communication between hosts with the new
kind of address space and those with conventional addresses.

I don't know much about IPsec, but if it is not unthinkable to break
 IPsec's AH mode, then that gives me some ideas for using bits in
the IPv4 header for purposes different than they are currently used.

  - Robin

---

From: Christian Vogt <[email-masked]>
Date: Fri, 8 Aug 2008 12:20:59 +0300

> or diffserv. These are both encoded fields, so there are no spare

You are right.  The bit that I thought was usable (the 6th-most-
significant bit in the DiffServ field) is already used to encode the
sub-group of DiffServ code points.  My mistake; apologies.

So back to Robin's suggestion to take the bit from the flow label...

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2008 13:10:32 -0700

Robin,

>spoofed ICMPv6 Error Message packets to the sending host.

Said another way, an approach in which hosts within
a site rely on PMTU messaging from anonymous routers
outside of the site is fragile at best and susceptible
to spoofing attacks. (The same is not true when hosts
only need to rely on PMTU messaging from trusted
routers within the site.)

Fred
[email-masked]