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

Re: draft-nordmark-multi6dt-shim-00.txt

marcelo bagnulo braun wrote:
When discussing fragmentation in section 5, i guess that the question that Margaret raised a while ago is still there i.e. if we place multi6 below fragmentation, what happens when we have a full MTU packet and we need to add an extension header? 

The packetization layer (such as TCP) needs to be aware of this,
which isn't any different than how an implementation makes TCP aware
that ESP or AH will be added to a packet, or that it will be subject to
IP-in-IP tunneling overhead.

In section 8.4 it is stated that:

   This might be the case when the two
   hosts have already communicated, and it might be possible to have the
   DNS resolver library provide alternate locators to the shim in the
   speculation that they might be useful.

I have two issues with this:
- first: wouldn't this impose a new RR or something similar? i mean how does the DNS knows that all the locators belong to the same endpoint? i guess this is not really compatible with section 7... 

I believe you are right, but it might be possible to solve this.

If the attempts to talk to the peer using another AAAA record
(which may or may not point to the same host) include the ULID then the peer can respond with "not me", which would allow the multi6
layer to try all the AAAA records which do point at the same host.

Of course, if there is only one AAAA record per host (but multiple AAAA records pointing at different hosts) this is just a waste of time.
Even if say, the multi6 layer tries 2 records out of 10 which happen to
point to the same host, but are unreachable (e.g. because the host is down), then the application layer needs to try the other 8.
But the application layer wouldn't know that multiple AAAAs have been tried by the multi6 shim below; it just has a list of 10 ULIDs to try.
So it would end up trying all 10.

- second: this would introduce a new way to learn additional locators (the noid like mechanism) This mechanism may have different trust levels than the one available for learning locators during the communication lifetime. Wouldn't this introduce some trust problems?

It does have different properties, but I don't think it matters in practice because it is the mechanism the host uses to learn different ULIDs.

   Erik