[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim - transport/app communication
Bound, Jim wrote:
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.
Nobody has proposed changing the IP addresses that are seen on the wire.
All we are changing is to add a dynamic mapping between what IP
addresses the transport and above sees (the ULIDs) and the IP addresses
the routing system sees.
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.
You mean carry TCP (and UDP?) over SCTP, or something different?
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'd like to understand why you think a DST option in every packet is
necessary. Such a thing would be complete untrusted. Thus it would be
better if middleboxes that want to do verification either
- get explicitly signaled from the endpoints so that they have the list
of IP addresses
- observe the sim6 signaling protocol and do the same verification as
the endpoints do as a way to discover the list of IP addresses
Both of those can be reasonably secure.
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.
I agree it shouldn't impact the rest of the Internet.
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.
I don't think "signaling protocols" need to change more than they need
to change to support SCTP (and in both cases this might be a host
implementation issue and not a protocol standard issue).
Suppose that one is using RSVP to setup reservations for some IP address
pair and port number pair. If the IP addresses change, whether it is
SCTP or the shim that does such a change, you'd want to do something
with the RSVP reservation (either change it to include all the addresses
that are used, or change it to use the new addresses).
So I think this level of change is inherest in the problem of wanting to
switch the IP addresses to have the communication survive, and
indepedent of the layer in the stack where we add the address agility.
Erik