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

Re: [manet] Three issues with PacketBB

Dearlove, Christopher (UK) wrote:
So two IPv4 addresses differing at the seventh most significant bit
will have to be encoded without a common head part - right? 

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. 

That "if present" is a pretty good hint that it doesn't have to
be present.
> 
But more importantly you missed

      bit 0 (nohead):  if cleared ('0'), then <head-length> is included
         in <address-block>, and <head> may be included in <address-
         block>.  If set ('1'), then <head-length> and <head> are not
         included in <address-block>.

As for including a <head-length> equal to zero, it's legal.
Not efficient, but legal.

Right... I've missed that semantics part, simply because I've never seen a protocol header having a 'address semantics' field. Semantics is to me something to be specified in node behaviour, like when node receives this bit does that, but not to encode in messages...

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). 

No, what I'm saying is that a node may use (using upper case letters
for 64 bits and a / to join them) A/Z and B/Z as two addresses of
the same interface, where Z is its EUI-64. Of course A and B may
also have some head bits in common, or may not.


Right, that Z is the tail part.

And 'mid'? 

mid is the uncompressed bit. Always is. Sometimes you have a common
head. Sometimes you have a common tail. Sometimes you have both.
Sometimes you have neither. mid is the bit in the middle that is
different. It can have zero length but that will be (I expect)
uncommon.

'mid' is one bit only? It seems to me it can have a length too: mid-length = address-length - head-length - tail-length.

Anyways, would you agree a simple way to encode a NEMO Mobile Network Prefix with PacketBB would look like this (ignoring head:mid:tail features)(would you confirm the values of question marks?):


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   <num-addr>  |<addr-semantic>|       <tlv-length>            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   <tlv-type>  |<tlv-semantics>|    <length>   |   Pad '0'     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-                                                             -+
     |                                                               |
     +-                       IPv6 Address                          -+
     |                                                               |
     +-                                                             -+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   <tlv-type2> |<tlv-semantics2|    <length2>  |  PrefixLen    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     num-addr: '1'

     addr-semantics:
              bit 0 (nohead):   '1'
              bit 1 (notail):   '0'
              bit 2 (zerotail): '0'
              bits 3-7:         '0'

     tlv-length: ?

     tlv-type:   ?

     tlv-semantics:
              bit 0 (extended):    '0'
              bit 1 (novalue):     '0'
              bit 2 (noindex):     '1'
              bit 3 (singleindex): '0'
              bit 4 (multivalue):  '?'
              bits 5-7:            '0'

     length: 0x10 ('16' decimal)

     IPv6 address: the IPv6 address that is the Mobile Network Prefix.

     tlv-type2: '0'

     tlv-semantics2: '?'

     length2: '?'

     PrefixLen: Eight-bit unsigned integer indicating the prefix length
                of the IPv6 Address.

I will post this separately as well.


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... 

But invisibly to IPv6. packetbb is just carrying the addresses.
It's up to a protocol that does know something about addresses
- maybe DYMO, maybe an autoconf mechanism that uses packetbb
to interpret those addresses. packetbb is NOT a protocol.


Well I agree PacketBB is not a protocol.

However, and this is something I've already remarked to DYMO, ignoring some fields present in the IPv6 base header (ie rfc2460) is not good either. Also ignoring how other protocols encode addresses (and subsequently specifying new means) is too much programming effort when reuse could be more efficient. Just IMHO.

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