Comments on draft-ohta-multi6-8plus8-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

> 1. Introduction & Terminologies
> 
>    This memo describes 8+8 address format,

There should be an acknowledgement here to Mike O'Dell, who invented both
the name and the original 8+8 proposal. Technically the current proposal
is different, but it is unfair not to give Mike the credit.

> 2.4.1 Locator Derived ID
...
>    That is, a site is assured to have 65,536 IDs assigned, though the
>    locator nature of the ID makes IDs not stable against site
>    renumbering.

There are three major problems with this:

1. 65k ids is not enough. If I take the example of my own company, we
would certainly want to appear as a single "site" for multihoming (at
many different ISP attachment points) but 65k hosts is nothing like enough.
In fact, with the massive scaling of devices that we expect with IPv6,
65k hosts won't be enough for companies with a few thousand employees.

2. As I understand it, each host burns up a subnet number. But in large
systems people expect to use toplogically significant subnet numbering,
and the numbering plan must survive any amount of moving of computers from
one building to another. That is incompatible with tying a subnet number
to a host.

3. As noted in the draft, renumbering breaks these IDs so they cannot be
regarded as having long term stability.

>    Note that ID assignment within a site can be arbitrary and will not
>    be consistent of intra site link structure. That is, an end with a
>    locator derived ID including a certain subnet id may be located
>    anywhere in the site, not necessarily in the subnet corresponding to
>    the subnet id.

This seems entirely inconsistent. It seems to say that when a host is
moved, its ID can no longer be derived from its locator. So what was the
purpose of deriving it that way in the first place? This doesn't solve
the problem of being limited to 65k IDs or to the problem of burning
one subnet ID per host. We might just as well use sequential allocation
of the last 16 bits of the ID.

>    If one want to hide its privacy in ID, one should use locator derived
>    ID for one's ends.

I see no privacy enhancement here. These IDs are just numbers, and they
are persistent (at least until the site is renumbered). If you want to
enhance privacy, the last 16 bits would need to be a temporary pseudo-
random value.

I think that only the location independent IDs of section 2.4.2
are really interesting, but as we have discussed often, it is not
obvious that a 64 bit space will really work for this. These
are old arguments from when we discussed the original 8+8 proposal a
few years ago.

> 4.1 Modification to TCP
> 
>    A new TCP option, Multi Address option, is introduced.

How are SCTP, UDP, and DCCP handled?

...
>    It is expected that 9 locators are enough for most ends, as a site of
>    the end can be multihomed to three lower level ISPs each multihomed
>    to 3 top level ISPs.  However, if an end has more than 9 locators,
>    which is a case with routers with more than 9 interfaces, TCP or
>    upper layer modules should be responsible to select 9 or less
>    locators to be used for the TCP connection.

It seems very doubtful architecturally to have a hard limit on the
number of addresses and to throw yet more address selection problems
onto every transport layer implementation. Yes, 9 addresses may cover
most cases, but the code will have to cover *every* case.

> 4.3 8+8 Adaptation Layers for Applications over TCP and DNS
> 
>    The 8+8 adaptation layers make end to end multihoming invisible to
>    applications over TCP and DNS, that is, applications using TCP
>    transport only without hard coded IP addresses.
> 
>    Some multihoming proposals try to introduce an adaptation layer in
>    the Internetworking layer to hide locator changes.  However, this
>    attempt does not make sense.  As demonstrated by NAT, rewriting of
>    addresses is, in general, not transparent to transport and
>    application protocols.  

But *reversible* rewriting, as originally proposed by Mike O'Dell and
found also in NOID for example, *is* transparent to IPSEC, transport,
and application protocols.

>     ... For example, transport layer checksum
>    computation involves IP addresses and is different for each transport
>    protocol that address rewriting can not be confined in the
>    Internetworking layer. 

Yes it can, if it is reversible.

>     ... Insertion or deletion of IP headers affects
>    MTU, which is also visible to the transport layer.

Correct.

>     ... Applications like
>    FTP transmit raw addresses in application data streams

And this works just fine if the rewriting is reversible.

From an architectural point of view, NOID, ODT, and their brothers keep state
in the two ends at layer 3 to allow the address to be restored to its original 
value. The current proposal, like LIN6, forces the state up into the transport 
layer. The original O'Dell 8+8 forced the state down into the border 
routers.

The common feature is that state is needed somewhere, and it consists of
a set of addresses, one of which is tagged "in use as locator" and one 
(perhaps the same one) is tagged "in use as identifier".

   Brian