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