RE: shim - transport/app communication

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

> Bound, Jim wrote:
> > Erik, thanks.  If we are to do this really I agree with 
> your mail below
> > technically.  The key is that the ULID is dereferenced to an address
> > whereever possible in the nodes stack and always on the 
> wire and if ULID
> > must be passed over the wire it must be in some encaped dst 
> option is one
> > suggestion.  Also how do I trust it on the wire?

> Are you concerned about the end-to-end behavior, or 
> routers/middleboxes 
> looking at the ULIDs and locators?

Yes and what must be on the wire are valid IP addresses in the header.
As we don't know what these will look like and how they are to be
managed it is uclear and not your shim spec
draft-ietf-multi6-l3shim-00.txt.  Add network management to that etc.
The point is that multihoming architecture should solve that specific
set of problems not cause any change to the rest of the network
operational infrastructure.  That is why I still believe SCTP is the
correct approach by adding ULID extensions, we are reinventing the
wheel.  The engineering cost and time to market for implementation will
be faster if we use SCTP and build TCP shims for multihoming. And we can
meet a reasonable time to market product set introduction.  The ULID for
the wire should be carried as a DST Option. I will wait for your next
spec to comment on how this can be done and slight changes to some of
the diagrams in the spec.  But figure your putting out a new spec soon
on that now, if not I can send you offline comments.  This effort should
not impact the rest of the Internet network implementations or it will
never happen. 

> The end-to-end behavior is trusted 
> using the HBA/CGA way to secure the relationship between the 
> addresses.

This was not my concern but I don't buy this entire belief of CGA and
either do many security viewpoints in industry. CGA is way over sold and
hyped.

> 
> If routers/middleboxes look at the packets (e.g. for QoS), 
> then in might 
> be best to have them use the locators (i.e., what's in the source and 
> destination address fields in the IPv6 header) since they are 
> as trusted 
> as today (which isn't very much). This means that signaling protocols 
> that today pass addresses to routers/middleboxes, need to 
> pass the set 
> of addresses instead of a single address.

Yes you discuss this in the draft above and left it that this may have
other problems.  I agree. But to my point above the multihoming solution
should not have to cause "signaling protocols" to change.  That is my
concern and most of my concerns are take care of if the src and dst
addresses are IPv6 addresses and only them in the header when entering
the wire.

Also what about MIBs, Intrusion Detection, etc all that assume IPv6
addresses which appear to be unaffected at least at IP layer 3-5.

/jim
> 
>      Erik
>