Subject: Re: [RRG] Arguments against Transport...

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2008 15:46:25 +1200

On 2008-05-22 13:04, Robin Whittle wrote:
...
> There has been discussion of "Transport" solutions.  If that means
> SHIM6,

Not in my book. Shim6 is by definition a shim *below* the transport
layer. In deference to Tony's request, I won't comment on the
misrepresentation of shim6 below, but I will respond on one
general point.

> this doesn't provide multihoming in a way which can be
> managed per site, rather than per host - and it only works with IPv6
> between hosts which are upgraded.  SHIM6 (or Six/One - not Six/One
> Router) does not provide portability of address space between
> providers, which is one of the major reasons for end-users wanting
> their own PI address space.

See slides 11 through 17 at http://www.cs.auckland.ac.nz/~brian/RRG0508.pdf
for my views on this topic. Frankly, I think that eventually,
enterprise IT people will understand that running multiple IPv6
prefixes when they have multiple ISPs, and adding and deleting
prefixes, is *not* an operational nightmare, but that lies in
the future.

>  Also, SHIM6 is not backwards
> compatible, unless it is accepted that the multihoming can only be
> provided for packets sent from from upgraded hosts.
> 
> What other "Transport" proposals are there?  

SCTP. Running code, like shim6.

    Brian

--
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: Randall Atkinson <[email-masked]>
Date: Thu, 22 May 2008 00:34:15 -0700

Earlier, Brian Carpenter wrote:
% Not in my book. Shim6 is by definition a shim *below*
% the transport layer.

I concur.  SHIM6 is a network-layer approach.

% Frankly, I think that eventually, enterprise IT people will
% understand that running multiple IPv6 prefixes when
% they have multiple ISPs, and adding and deleting prefixes,
% is *not* an operational nightmare, but that lies in the
% future.

I don't know what the future holds.  I agree that such an
approach ought not be an operational nightmare.  This
might partly be a matter of educational/informational
material being made available.  It might also be having
the IETF work on its standards so that such operation
is simpler in future than it is perceived by many IT folks
to be at present.

> What other "Transport" proposals are there?

% SCTP. Running code, like shim6.

Yes, and conceptually at least, similar architectural
approaches could be undertaken as incrementally
deployable changes to TCP and UDP.

(In such a case, it would be important for the IETF
to specifically document how firewall implementers should
add this support, as the firewalls (and other middleboxes)
are likely to be the sticky wickets in any deployment.
But the details of that are IETF issues, not IRTF issues.)

So I see at least 4 classes of solution under
consideration here:

- Network-layer protocol changes
- Transport-layer protocol changes
- Map & Encapsulation/Tunnelling by routers
- Network-layer NAT/NAPT approaches
- other ??

Ran
[email-masked]