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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jan 2004 14:16:44 +0100

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 23:44:34 +0900

Brian;

> is different, but it is unfair not to give Mike the credit.

8+8 is a generic terminology. It was used at least in 1994 in
big-internet ML. Note that Mike O'Dell, you and I were members
of the ML atthat time. Maybe, Mike O'Dell was the first person
to use the terminology "8+8" somewhere else. But, Mike O'Dell
and others used it as a generic terminology.

Archive of big-internet can be found at:

	ftp://munnari.oz.au/big-internet/list-archive

Later, Mike O'Dell made a proposal. It was named GSE.

My architectural draft made it clear from the beginning:

   Note that 8+8 proposal must not be confused by latter proposal of
   routing goof (GSE) by Mike O'dell, which is a proposal to use
   intelligent routers to rewrite source addresses to prevent source
   address spoofing and to tunnel between intelligent routers for pseudo
   multihoming, both of which are against the end to end principle and,
   thus, lacks robustness and/or scalability.

Read the draft.

> 1. 65k ids is not enough.

I never said 64K ID enough and the draft describes how the problem
can be solved.

However, you are too pessimisitic.

> If I take the example of my own company, we

If your company has so many external connections, your company has
a lot more than 64K locator derived IDs that your company don't
have any problem.

BTW, it is unwise that your company appears as a single "site"
for multihoming, because it makes your company valunerable to
internal link failures.

> one building to another. That is incompatible with tying a subnet number

There is no tying. My draft says:

	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.

> regarded as having long term stability.

Of course, not.

But, it should be noted that the longevity is expected to be
longer than that of hash of public keys, because security
sensitive people change keys more frequently than ISPs.

Those who need even better longevity are taken care of by
the draft.

> moved, its ID can no longer be derived from its locator.

No.

The draft says:

	IDs may be derived from locators allocated to sites.

not

	ID may be derived from a locator allocated to an end.

But, I try to further improve the explanation.

> enhance privacy, the last 16 bits would need to be a temporary pseudo-

Wrong. Your locator is persistent and is known by your peers
that there is no point of hiding it.

> are old arguments from when we discussed the original 8+8 proposal a

It is an older argument positive answers to which can be found in
bigi archive.

> How are SCTP, UDP, and DCCP handled?

Read the draft.

> most cases, but the code will have to cover *every* case.

9 is not a hard limit. Read the draft.

> and application protocols.

Mike O'Dell imitated existing 8+8 proposals to modify TCP and
other transport layer protocols not to include locator
part for checksuming and IPSEC calculation, which is a
modification to the transport layer protocols. Of course, it is
not transparent to application protocols like FTP.

GSE draft says:

   One immediate result is that upper-layer protocols must use only the
   ESD for purposes such as pseudo-header checksums and the like.

> The original O'Dell 8+8 forced the state down into the border 
> routers.

That's why only way to make it transparent to IPSEC and transport
is not to protect locator by IPSEC nor transport checksums.

You should not rely on your memory and check appropriate references
when you want to say something in the past. I do check them.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jan 2004 19:30:23 +0100

Factually, Mike first published a pure 8+8 proposal in 
draft-odell-8+8-00.txt in October 1996. GSE came later,
in draft-ietf-ipngwg-gseaddr-00.txt in February 1997.

Apart from that, I am aware of the history and I did read
the current draft before making my comments.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jan 2004 18:25:13 +0900

Brian E Carpenter wrote:

> draft-odell-8+8-00.txt in October 1996.

If you say ID "published", I published a pure 8+8 proposal in
draft-ohta-ipv6-addr-arch-00.txt in March 1995, though I'm
not sure it was the first one of mine. The draft, for example,
says:

   By separating a 128 bit IPv6 address into 64 bit ILOC (Internet
   LOCator), first 4 bytes of which is flat routable provider part and
   the rest 4 bytes of which is hierarchical intra-provider part, and 64
   bit IID (Internet ID), which is not routable but globally unique, it
   is possible to preserve some of the provider independence of IPv4.

Other people were publishing their own 8+8 proposals then.

> the current draft before making my comments.

You should read the past draft, because you made request directly
involving them.

In draft-odell-8+8-00.txt, it is written

   The addressing model proposed here is called "8+8" to distinguish it
   from the existing proposals which are called "Flat-16" in this
   document.

but such addressing model can be found in XNS and the model
has been discussed in big-internet ML before 1994 that there
is no originality. Moreover, there are other drafts, including
mine, on the idea which predate Mike's.

						Masataka Ohta