[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt



Iljitsch van Beijnum wrote:
> 
> On 14-jan-04, at 7:55, Brian E Carpenter wrote:
> 
> > 1. It seems to me that if you ignore the way each of them is
> > described, there is actually a very strong resemblance between ODT and
> > NOID. In effect they both treat the first address used for a session
> > as the ID, and dynamically switch to using alternative addresses as
> > the locator, with a stateful shim concealing the switch from upper
> > layer protocols. Am I confused?
> 
> Yes, this part is the same. However, I wouldn't say that
> 
> > the crude description of ODT is as a degenerate case of NOID.

No, I didn't think you would say that :-) But I think when we start
the architectural analysis, ODT and NOID will come out very similar.

> 
> The shim idea wasn't new in NOID either.
> 

Certainly not.

> I didn't include address rewriting in routers in ODT because although
> the idea is very interesting, I don't think the potential gain is big
> enough to justify all the additional trouble. 

And that is an architectural choice the WG may have to make at some point.

> Also, NOID uses a
> three-way handshake while ODT uses a model where each end announces
> information to the other end that may or may not be ignored.

Yes, so the state machines are a bit different too.

> 
> > 2. One remark that I really don't understand:
> 
> >> 8 Tunnel Creation
> > ...
> >>     1. Host A announces its addresses to host B
> 
> >>     The addresses may be of different address families. Each address
> >> is
> >>     accompanied by preference information. In order to not
> >> unnecessarily
> >>     trigger NAT incompatibility, a "current source address" address
> >>     family is used to refer to the source address in the IP packet,
> >>     which may have been rewritten.
> 
> > Firstly, we aren't designing for IPv6 NATs, so this would only apply
> > to the IPv4 case, right?
> 
> I hope so.  :-)
> 
> > But in any case, I don't see how it helps. You
> > can't tell by looking at an address whether it's been rewritten, so
> > you can't tell if it's OK for checksum purposes.
> 
> Which checksum do you mean here?

Any, really. We use addresses in TCP checksums or crypto checksums, and when
they get NATted things break unless somebody knows to recreate the checksum.

   Brian