Re: Comments on multi6dt documents

> With this clarifying example (the temporal element to the address 
> ownership) I think the potential issues this brings up are clearer. Thanks.

ok. I'll add it to the draft.


> Agree that NAT is a loaded word and better avoided.  I used it to refer 
> to the fact that address mapping seems to be required, as well as rather 
> NATty behaviour or looking at the payload and interpreting the content 
> in some manner, and trying to mangle it.

Per this definition I think header compression would be categorized as a 
NAT, because it mangles the packet. The difference with multi6 and 
header compression is that the mangling will be undone i.e. the output 
at the other end will be the same as the input. This isn't the case for 
NAT, which is why I think using that term here adds confusion.

> 
> The sender needs to be able to demux a packet it sent based on the 
>> first 64 bytes.

I misremembered the ICMPv6 spec about the size of the returned offending 
packet. It will be more like 1000 bytes (as much of the offending packet 
that fits without exceeding 1280 bytes for the ICMP error).

> Unless we can make some simplifying assumptions here it seems like 
> bringing up issues described in section 2.1.9 of 
> draft-savola-v6ops-security-overview-03.txt and prior to that in a 
> different draft -- i.e., the nodes must be able interpret and process, 
> or skip over -- all the possible headers out there.

Are you saying the middleboxes will inspect, not the IP+ICMP part,  but 
the offending packet contained in the ICMP error?
There might be concern about adding an extension header to get e.g. 
IP+EXT+TCP and what that does to the packets in middleboxes, but the 
context of this piece of the discussion is the ICMP errors, right?
If the middlebox lets through IP+EXT+TCP then presumably it will allow 
the error which is IP+ICMP+IP+EXT+TCP in the reverse direction.


> Just demuxing the packet (and doing reverse mapping if needed) would be 
> one thing, but don't you also have to parse inside the packet and 
> translate that back as well?  Then the implementation should have to 
> know which protocols to parse and how, i.e., where the "juicy bits" to 
> look are.

Yes, the implementation needs to be able to pass the indication that an 
ICMP error was received to the correct ULP "connection", which involves 
finding the ULIDs that were used before the shim did its work on the 
xmit side.
The details of this depends on how the internal interfaces in the 
implementation for delivering notifications about ICMP errors to the 
ULPs; does it deliver the actual ICMP packets or something more abstract,

So it involves writing code in an implementation and should be noted in 
the draft. Is it hard? No.


>> Yes.
>> But since this is added by the sender and not something in the middle
>> many of those concerns (such as ICMP too big not getting through) do 
>> not apply. But we should discuss this further in the draft.
> 
> 
> Agreed.  Protocols such as UDP probably incur fragmentation and TCP just 
> adjusts.

Yes, sending e.g. 8k NFS packets over UDP has been observed to cause 
fragmentation :-)

But since the added bytes are on the sending host an implementation 
should be able to do a good job of fragmenting things. Thus there isn't 
a need to end up with one 1500 byte piece followed by an 8 byte fragment 
followed by 1500, 8, 1500, etc.

    Erik