[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ohta-multi6-8plus8-00.txt
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.
Masataka Ohta wrote:
> > 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.
> 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:
> 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.
> >>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.
> 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
> > would certainly want to appear as a single "site" for multihoming (at
> > many different ISP attachment points) but 65k hosts is nothing like enough.
> 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.
> > 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.
> 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.
> > 3. As noted in the draft, renumbering breaks these IDs so they cannot be
> > 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.
> >> 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.
> The draft says:
> IDs may be derived from locators allocated to sites.
> ID may be derived from a locator allocated to an end.
> But, I try to further improve the explanation.
> >> 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.
> Wrong. Your locator is persistent and is known by your peers
> that there is no point of hiding it.
> > 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.
> It is an older argument positive answers to which can be found in
> bigi archive.
> >>4.1 Modification to TCP
> >> A new TCP option, Multi Address option, is introduced.
> > How are SCTP, UDP, and DCCP handled?
> Read the draft.
> >> 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.
> 9 is not a hard limit. Read the draft.
> >>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.
> 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM