Re: Flow label versus Extension header

[Brian E Carpenter <[e-mail]>]

I wonder if Jeroen is mixing the shim6 state establishment
protocol (which we have never discussed in detail) and the
context tag (which is explained in draft-ietf-multi6-l3shim-00.txt)?

And I don't know what a shim6 gateway is. Shim6 is basically
designed host-to-host.

    Brian

marcelo bagnulo braun wrote:
> 
> El 20/04/2005, a las 17:26, Jeroen Massar escribió:
> 
>>
>> Extension Header is IMHO the best step. Overloading the Flow label is
>> not a good idea, if we want that then we should bump the version of the
>> protocol and include this directly in the specification.
>>
>> Actually what would be preferred to me is to have a packet like:
>>
>> [ routing-src : 128bits / 16 bytes ]
>> [ routing-dst : 128bits / 16 bytes ]
>> [    site-src :  64bits /  8 bytes ]
>> [    site-dst :  64bits /  8 bytes ]
>>
>> This does indeed not allow 'host' multihoming but saves 8 complete
>> bytes. The site-src/dst could even be made optional in case the source
>> site supports shim6 but does not do any shim6 itself (or define src=::
>> to specify no translation?)
>>
> 
> I may be missing what is site-src and site-dst...
> 
> What i had in mind to carry in the extension header was just a context 
> tag, just a random value that can be used to identify the context 
> established between the peers. This context tag extension header needs 
> only to be included what the addresses carried in the packet differ from 
> the ULIDs associated with the context.
> 
> However, i feel that you have a different idea with this site-src and 
> site-dst... could you expand on this?
> 
> Regards, marcelo
> 
> 
>> And people, how much 'overhead' is 16 bytes on the many megabytes that
>> one will transfer? We are unfortunately not in the era anymore that
>> webdesigners simply make an HTML page it has to include a lot of images,
>> flash and other mumbo jumbo. As Marcelo mentions the above would only be
>> sent for the first packet using this pair of addresses.
>>
>> Also a shim6 gate can easily drop this extension header when doing the
>> de-multiplex/de-nat thus making this completely transparent for the
>> outer hosts. Maybe a creepy thing: multiple 'stacked' headers like these
>> and doing shim6-in-shim6... but let's forbid that 'feature' ;)
>>
>> Btw this comes awfully close to some space-port writeup I've seen once.
>>
>> Greets,
>>  Jeroen
>>
> 
> 
>