RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

Your chances of another API other than 3493 and getting multihomed
solution deployed in the real world of implementors and products is very
slim.  I also do not believe this is necessary.  The ULID concept
requires much more details and grilling technically. 
/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Sunday, March 20, 2005 4:00 AM
> To: Baker Fred
> Cc: shim6
> Subject: Re: shim - transport/app communication
> 
> On 19-mrt-05, at 22:32, Baker Fred wrote:
> 
> >> the only thing an application should depend on here is that it 
> >> supports IPv6 addresses
> 
> > If I could make a humble request here...
> 
> > Could we please manage to avoid the worst of the layering faults we 
> > committed in the IPv4 Internet? The thing that has made NAT 
> hard and 
> > made applications break crossing a NAT was that the 
> applications know 
> > something about addresses. Let's not do that with IPv6 applications.
> 
> It's already done. The RFC 3493 API extensions require an application 
> to know about IPv6, if only because they have to specify AF_INET6. In 
> theory, that's it, but in practice it's much worse because an IPv6 
> application really needs to cycle through all available addresses, 
> which IPv4 applications rarely do. Then there is the whole 
> IPv4-mapped 
> implementation debacle that makes writing (portable) 
> applications that 
> support both IPv4 and IPv6 rather tricky.
> 
> The only real solution that I can see here is yet another API that 
> moves address resolution out of the application, and completely hides 
> the IP version from the application.
> 
> The good news is that there should be some time to get it 
> right before 
> we need to move to whatever comes after IPv6.  :-)
> 
> 
>