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

Headers

[doing some aggregation]

RJ Atkinson:
> Perhaps providing a reasonably strong binding between the identifiers
> and locators in some initial packet(s), and having subsequent packets
> only contain the locators (at least until a locator changes) might be the
> right model.


That might well be reasonable.  One would want to see the details 
before

drawing a firm conclusion, of course.




In my book, "reasonably strong binding" means some form of 
cryptographic

authentication.



I'm imagining a situation (see my "transportzilla" posts from a while 
back for more details) where the application uses an identifier which 
doesn't have to be an address, and TCP and UDP use this identifier in 
the pseudo-header. IP only uses the locators. So there must be a 
mapping between the locators and the identifiers between IP and TCP. As 
long as each combination of { any source locator, source port, any 
destination locator, destination port } is unique on both ends, there 
shouldn't be any trouble finding the right source and destination 
identifiers on the destination host. Of course there is the minor 
detail of setting up all this state...



This should bind the identifiers to the locators strong enough without 
any per-packet overhead as long as the setup phase is well-secured. Of 
course there are still the traditional TCP weaknesses but the billions 
of packets flowing around the net every second tell us most people can 
live with this most of the time and there's always TLS and IPsec.



J. Noel Chiappa:


One way to "include" the identifier in each packet implicitly (i.e. 
make

sure the packets get to the right endpoint) is to include the endpoint

identifier in the transport "pseudo-header", so that you get a checksum

failure if the packet gets to the wrong endpoint.



Yes. But: packets shouldn't end up at the wrong session anyway unless 
something is seriously broken and this provides no protection at all 
against someone who can intercept the communication as the TCP checksum 
is hardly a one-way hash.




I hypothesized an small, short, endpoint identifier with scope local 
to the

destination (I called it an ESEL, for "endpoint selector") to 
disambiguate

when you have multiple endpoints at a single locator.



Wouldn't this be similar to a port number (for outgoing connections) or 
an IPsec SPI?




I would suggest that 16+16 be done not with a complete second IPv6 
header,

but rather one of the routing headers (I forget the formal name). That 
would

make it somewhat smaller.



Which identifier do you need? The source or destination? The trouble is 
the 8 byte alignment in IPv6: this is enormously inconvenient when you 
need to add something that is also 8 byte aligned because you then need 
8 bytes just to say there is an extra header. (Lets remember this for 
IPv7: no 2^x sized addresses!) This means a second IPv6 header is the 
shortest way to add both a source and a destination identifier. So then 
we're tunneling.




Anyway, why does header size matter that much? Those on slow links (< 
56K)

will be using header compression anyway, so it doesn't really matter 
for them

since the average packet will have all that stuff compressed out 
anyway, and

for those on fast links, who cares about a few extra bytes?



Short answer: someone should! If we're going to do 2 IPv6 headers the 
additional 60 bytes per packet aren't going to persuade anyone to 
switch. The average IP packet size is around 500 bytes, so that's 10% 
of your bandwidth you're throwing away by switching. Header compression 
is great, but it doesn't solve everything. For instance, my iBook has 
RFC1323 extensions enabled by default. This makes the TCP header 12 
bytes longer (yeay!) but also unpredictable.



Also, all these headers at every layer add up. 11 Mbps wireless? Don't 
make me laugh: you're lucky if more than half is usable payload.



If we can accomplish the same functionality without the extra headers, 
we should do it without.




Check out the average web page to see how many stupid little icons it 
has on

it, how many JavaScript files it loads, how many pop-up windows (with 
their

own images and Javascript) it loads, etc, etc. (Every Web page 
designer ought

to be sentenced by law to using a 28.8 modem for all their online 
access...

but I digress.)



So we should do basically the same thing, but then for the entire 
internet where everyone is forced to eat the extra overhead the next 15 
years or so? At least I have a choice when visiting websites, there are 
only a few flavors of IP around...



marcelo bagnulo:


In order to preserve aggregation, renumbering is required when changing
ISP, this is why end-sites like PI.





Now, the separation of identifier and locator can help with this,

simplifying re-homing events and renumbering. I guess that this

separation can help in such events. Currently internal systems such as

access lists, firewall use IP address for filtering, so that if the 
site

renumbers all these list have to be updated. If id-locator separation 
is

implemented, these systems can use identifiers, that belong to the end

site, symplifying re-homing events. In order to do this, identifiers

need to be carried in packets.



You can't take what's in a packet at face value: this information can 
be spoofed. I would rather have the firewalls take part in the session 
establishment procedure. Then you don't need the explicit identifiers 
as per the above.



Iljitsch