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

Re: [manet] Three issues with PacketBB

Dearlove, Christopher (UK) wrote: 
I'm replying to this one, but I may cut it off then, as
time presses on other things.

That's fine, thanks. I am curious to hear others' oppinions as well and or wait for your replies later.

I think we don't understand each other.  I don't see how is it
possible
to disambiguate two addresses represented as head-tail if we don't
precisely encode the headlength.  Receiver simply can't decode
correctly
a field saying 3octets when sender meant 26bits. 

It's really very simple. Take your example of 1.1.1.1 and 1.2.2.2.
This actually has 30 common bits. But we work in common octets
and it has 3.
> So we send (noting that the different pieces are 
mids, not a common tail) what reports that

Head octets = 1
Tail octets = 0
(and hence mid octets = 3, as addres length = 4)
Head octet 0x01
First set of mid octets  0x01 0x01 0x01
Second set of mid octets 0x02 0x02 0x02

And it's all there.

So two IPv4 addresses differing at the seventh most significant bit will have to be encoded without a common head part - right?

In this case, the spec doesn't seem to say whether a head-length is absent or present but equal to 0: 
   <head-length>  if present is an 8 bit field, which contains the total
      length (in octets) of the head of all of the addresses.

   head-length  is a variable, defined to equal <head-length> if
      present, or 0 otherwise.

   <head>  is omitted if head-length == 0, otherwise it is a field of
      the head-length leftmost octets of all the addresses.

It seems to say that head-length must be present and equal to 0. It would be present and adding to unnecessary overhead?

Also please allow me to question the necessity of the 'mid' part of an
address.


Two main reasons

- IPv6. A node may (I understand) use a common EUI-64 identifier for
  more than one interface, but with different prefixes. This would
  correspond to have a tail length of (at least) 8 octets.

YEs, but this doesn't show the necessity of the third 'mid' part. There are only two parts: head and tail ('head' is first 64bits and 'tail' is the Interface ID or EUI-64).

- Network addresses. If I want to send e.g. 10.0.0.0/16 and 10.1.0.0/16
  then I have a common head (1 octet, 10) and a common tail (2 octets,
  0 and 0 - I can use the zerotail bit to avoid sending these).


And 'mid'?

[Generally I'm ok - I think I understand the compression effects of
 head-mid-tail type of encoding addresses.  Maybe if more indexes
 (head-uppermid-lowermid-tail) are used then more compression can be
 achieved.  But this looks so different compared to other protocols I'm
 used to.  ROHC compresses headers not addresses - why not using ROHC?.
 Mobile IPv6 message encodings don't compress addresses.  Bandwidth is
 very high on some links.  Etc.]

I would find strange PacketBB to carry IPv6 addresses and not refer to rfc2460. 

We're only dealing with addresses, so we just need to refer to
IPv6 address architecture. And that's RFC 4291 (recently
obsoleted RFC 3513 which we do refer to.)

YEs, I agree, but there is much more here than just IPv6 address architecture once you say PacketBB packets are transported in UDP over IPv6...

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________


_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet