Subject: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:31:46 +0200

Dear MANETers.  I'm trying to find out how to encode an IPv6 Mobile 
Network Prefix using PacketBB encoding rules.  This is very important 
step in trying to use a MANET routing protocol in the MANEMO topologies, 
because eventually Mobile Network Prefixes have to be exchanged not only 
by the NEMO protocol but potentially by the MANET protocol as well.

Reading the PacketBB spec, and with some helpful clarifications, I came 
up with the datagram I present first.  I would need help to do the 
following:

-first please confirm the encoding is correct.  Are fields at right
  places, are the field lengths correct, have I missed any field, have I
  added too many fields, have I used padding correctly?
-second please help me fill the values for the '?' marks.
-finally, please compare the encoding with another encoding of the IPv6
  Mobile Network Prefix presented at the end of the message.  I think the
  latter uses less bytes to encode.  Can I use the latter encoding but
  expressed with PAcketBB terms?

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

Other (possibly simpler?) possible way of encoding the IPv6 Mobile 
Network Prefix, but not with PacketBB:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |   Length      |   Reserved    | Prefix Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                   Mobile Network Prefix                       +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 16:42:40 +0100

> I came up with the datagram I present first.

I'm afraid I don't have time to comment on this.
But that Pad octet is clearly out of place.
Padding occurs (optionally) only after a packet
header or a message.

Also see Thomas's comments.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:49:53 +0200

> I'm afraid I don't have time to comment on this.

Thanks, I request MANET community to comment on that PAcketBB encoding 
of the IPv6 Mobile Network PRefix - thank you.

> Padding occurs (optionally) only after a packet

Ok, I moved Pad '0' at the end, it looks like this, is this better?

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

> Also see Thomas's comments.

I hope someone can comment on this packet format: ok or not ok, how 
should I encode it better?

Thanks,

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 16:57:16 +0100

> should I encode it better?

Again, without studying it, what I would recommend
is to take the regexp that is the formal definition,
and break what you have down to match the elements
in the regexp.

As a starting exercise, take the example packet in
Appendix B and do that to that. (You should actually
be able to do it without reading the text before the
example.) Hopefully you'll find it can be so decomposed.

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 18:00:08 +0200

On Jun 19, 2007, at 5:49 PM, Alexandru Petrescu wrote:

> Thanks, I request MANET community to comment on that PAcketBB  
> encoding of the IPv6 Mobile Network PRefix - thank you.
>

I still do not think that it is clear what it is you are trying to  
encode, and your figure doesn't help. What is it that you are trying  
to do? In your figure, it seems that you are trying to have part of  
an address block header and then a TLV block followed by an IPv6  
address.....then another TLV block and some padding.

Doesn't look to me as this encoding would be compatible with  
packetbb, but if I understood what it was you were trying to do, then  
I am sure that it could be encoded.

Have you looked at draft-ietf-manet-packetbb (here's an URL: http:// 
www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt)  
section 5 for the description of the format, and  appendix A for  
illustrations? It should provide you with inspiration as to how you  
can encode things, once they're specified, and examples of how the  
actual layout would be in the familiar IETF-pictures.

If all you want is a single IPv6 prefix, then you'd benefit little  
from any aggregation, and a message TLV with explicit content might  
simply do the trick. But, I am not sure I understand if that is what  
you are looking for.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 18:09:13 +0200

Dearlove, Christopher (UK) wrote:
> Again, without studying it, what I would recommend is to take the 
> regexp that is the formal definition, and break what you have down to
>  match the elements in the regexp.

That's what I did.

('regexp' means different things to different people: "?" has different
  meanings in gnu regexp vs dragon book - which one did you use?
  Besides, I'm not used to reading messages specified with grammar
  syntaxes, but I could try to understand the Augmented Backus-Naur Form
  RFC4234 which incidentally doesn't use '?' at all.)

> As a starting exercise, take the example packet in Appendix B and do 
> that to that. (You should actually be able to do it without reading 
> the text before the example.) Hopefully you'll find it can be so 
> decomposed.

I've tried that too.  But it uses IPv4 addresses; and head-mid parts.
DYMO example too uses IPv4 addresses.  My example only needs to encode
one address so it doesn't use head-mid-tail parts.

The example in Appendix B is very useful when one needs IPv4 encoding
and sending two or more addresses.

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 17:11:06 +0100

Defined in the Terminology section.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 18:16:33 +0200

Thomas Clausen wrote:
> Have you looked at draft-ietf-manet-packetbb (here's an URL: 
> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt)

YEs I've looked at these sections.  I have plenty of remarks on them.  I
refrain from writing remarks about the way that section is written, for
fearing of risking be not well understood.

All I need is a consensus-based PacketBB message that contains an IPv6
address with an IPv6 prefix length on it.  Just one, not two.  No
head-mid-tail and no index-start nor index-stop.

I've tried to propose one as I understand it.  Would you please remark
whether you agree with that message or not and why - thank you.

> simply do the trick. But, I am not sure I understand if that is what

YEs, that is what I am looking for: a PacketBB message TLV with explicit
content, containing an IPv6 Mobile Network Prefix (an IPv6 address and
the prefix length).

Alex

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 18:19:32 +0200

>  RFC4234 which incidentally doesn't use '?' at all.)

The "?" and other such symbols used are described in the terminology  
section, exactly recognizing that it might be differently interpreted  
if not defined.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 18:25:31 +0200

> Defined in the Terminology section.

Yes, ok.

Alex

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 18:28:06 +0200

> head-mid-tail and no index-start nor index-stop.

Let me play devils advocate: you want a packetbb message that's not a  
packetbb message?

> whether you agree with that message or not and why - thank you.

Ok, I do not agree with that message you proposed. Why? Because it is  
not a validly formed packetbb message.

> content, containing an IPv6 Mobile Network Prefix (an IPv6 address and

Very well. Seeing that you want that and only that one single prefix  
ever, then I'd go with a message TLV and an explicit representation  
of the prefix. See the examples in appendix A for how such a message  
TLV would look.

However if you might have more prefixes to advertise, or more  
addresses, then this would not be the efficient solution. But, I feel  
that you're either aiming for a very specific situation -- or for  
demonstrating something specific -- so I am not sure to which extend  
it is helpful that I comment on that without knowing the whole design- 
space you are considering.

Please do not take this as not-wanting-to-help -- but as the prudence  
that good engineers have to exhibit in not proposing a solution  
without understanding the problem and the design-space.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 21:17:05 +0200

Thomas Clausen wrote:
>>> I still do not think that it is clear what it is you are trying
>>> to encode, and your figure doesn't help. What is it that you are
>>> trying to do? In your figure, it seems that you are trying to
>>> have part of an address block header and then a TLV block
>>> followed by an IPv6 address.....then another TLV block and some
>>> padding. Doesn't look to me as this encoding would be compatible
>>> with packetbb, but if I understood what it was you were trying to
>>> do, then I am sure that it could be encoded. Have you looked at
>>> draft-ietf-manet-packetbb (here's an URL: 
>>>  illustrations? It should provide you with inspiration as to how
>>> you can encode things, once they're specified, and examples of
>>> how the actual layout would be in the familiar IETF-pictures.
>> 
>> YEs I've looked at these sections.  I have plenty of remarks on
>> them.  I refrain from writing remarks about the way that section is
>> written, for fearing of risking be not well understood.
>> 
>> All I need is a consensus-based PacketBB message that contains an
>> IPv6 address with an IPv6 prefix length on it.  Just one, not two.
>> No head-mid-tail and no index-start nor index-stop.
> 

Hehe... no, I want a packetbb message that shows how one IPv6 Mobile
Network Prefix (an IPv6 address and its prefix length) is encoded.

If that packetbb messages forces the use of fields head-mid-tail and of
index-start and index-stop then so be it, I just want to see it
correctly.  But I understood some of these fields are somehow optional.

>> I've tried to propose one as I understand it.  Would you please
>> remark whether you agree with that message or not and why - thank
>> you.
>> 
> 

Would you help illustrating a correctly-formed packetbb message
containing one IPv6 Address with its prefix length?  This is very useful
  for MANEMO advancement.

>>> If all you want is a single IPv6 prefix, then you'd benefit
>>> little from any aggregation, and a message TLV with explicit
>>> content might simply do the trick. But, I am not sure I
>>> understand if that is what you are looking for.
>> 
>> YEs, that is what I am looking for: a PacketBB message TLV with
>> explicit content, containing an IPv6 Mobile Network Prefix (an IPv6
>> address and the prefix length).
> 
>  ever,

Ok, I understand what you mean.  It's not that only one prefix will ever
be sent, but just that generally people understand better when one
prefix is illustrated and then explained how more prefixes can be
encoded.

> then I'd go with a message TLV and an explicit representation of the
> prefix. See the examples in appendix A for how such a message TLV 
> would look.

Ok, thanks.  But Appendix A has 38 messages into it - which one?  There 
are 6 subsections called "Packet", "Message and Padding", "Message 
Body", "Address Block", "TLV Block" and "TLV".  None of them is called 
"message TLV".  To be quicker, it would be easier if you could just 
paste from that Appendix which one do you mean, don't you think?

Do you mean this? (yes/no?):

> Appendix A.6.  TLV

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |Resv |M|0|0|0|0|  Index Start  |  Index Stop   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                             Value                             |
      |                                                               |
      |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |
      +-+-+-+-+-+-+-+-+

Is this format sufficient to represent an IPv6 address and its prefix? 
Two of these?

> it is helpful that I comment on that without knowing the whole
> design-space you are considering.

I think we understand each other well at this point.

I'm aiming first to encode an IPv6 Mobile Network Prefix.  Once I see 
how one is encoded then I can understand if and how several prefixes can 
be encoded.

Encoding one IPv6 Mobile Network Prefix is very commonplace in some NEMO 
implementations.

> without understanding the problem and the design-space.

Yes, right... that's exactly what I'm trying to describe for MANEMO - 
design space of using MANET routing protocols for MANEMO, and one 
problem is that I simply don't know  how to encode an IPv6 Mobile 
Network Prefix in the UDP payload of a MANET protocol (with PacketBB).

There are other issues that need to be discussed, some have already been 
raised, more to come.  But let me first identify this PacketBB encoding 
of an IPv6 Mobile Network Prefix.

Alex

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 20 Jun 2007 13:30:02 -0400

Here is a quick attempt of at an example packet looking to do what I think
you are wanting to do.
Sample IPv6 values used addr=2001:471:1f11:246::  prefix=64

A packetbb packet is
<packet> = {<packet-header><pad-octet>*}?
                  {<message><pad-octet>*}*

We don't need the packet header or more than one message for this example
so.
<packet> = <message><pad-octet>*

A message is defined by
<message>         = <msg-header>
                    <tlv-block>
                    {<addr-block><tlv-block>}*

<msg-header>      = <msg-type>
                    <msg-semantics>
                    <msg-size>
                    <msg-header-info>

<msg-type> is a required and is an 8 bit field.  For this example lets use a
value of MANEMO_TYPE 
           doing this one would be required to set the requirements of how
packetbb is to be used and for
           official use one would have to get an iana assigned message type.

<msg-semantics> 11110000 <-describs an empty msg-header-info field
(alternatively one could use the 
                          o-address field if there was only ever one network
to describe and use the 
                          message tlv to give the netmask of that address.)

<msg-size> this one we will come back to as it includes fields we haven't
gotten to yet is a required 
           16 bit field though

An empty msg-header-info field as defined by the msg-semantics, empty in
this case meanting non-existant.
Notice that all fields are optional and in this case not used.
<msg-header-info> = <originator-address>?  
                           <hop-limit>?
                           <hop-count>?
                           <msg-seq-number>?

<tlv-block> = <tlv-length>
              <tlv>*  <- not required with tlv-length of 0

We don't need any information here so 
<tlv-length> = 0 (16 bits)

So far we have
<message>         = <msg-header> <- defined
                    <tlv-block> <-defined
                    {<addr-block><tlv-block>}*
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|   <msg-type>  |<msg-semantics>|          <msg-size>           |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|  <tlv-length> (block       )  |  {<addr-block><tlv-block>}*
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MANEMO_TYPE   |    11110000   |               ?               |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|               0               | {<addr-block><tlv-block>}*
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For this case our message MANEMO_TYPE would define that at least one
addr-block and one address tlv
block is required.

<address-block> = <num-addr>       will be 1 for this case (8 bits)
                  <addr-semantics> turn off the head fields and set the
zerotail bit 10100000 
                  <head-length>?   <-not needed for one address
                  <head>?          <-not needed for one address
                  <tail-length>?   <-to compress the address we will set the
tail length of 64.
                  <tail>?          <-not needed with zerotail bit set
                  <mid>*           mid-length = 128 - 0 - 64 
<num-addr> = 1 (8 bits)
<tail-length> = 64 (8 bits) (zerotail bit is set so tail consists of all
zeros)
<mid> = 2001:471:1f11:246 (in hex 64 bits)

<tlv-block> = <tlv-length> don't know how large it is yet we will fill this
in later (16 bits)
              <tlv>*

<tlv> = <tlv-type> 8 bits lets use the PREFIX_LENGTH type specified in
packetbb section 6.1 so type is 0
        <tlv-semantics> 00010000 <-denoting an 8 bit length field and a
single index
        <index-start>?  <-this will be set to 0 (8 bits) indicating the
first (only) address
        <index-stop>? <- this will not be included because of the semantics
bit singleindex being set
        <length>? <- 8 bit field set to 00000001  (note: we need to specify
that single-length is in octets not bits)*
        <value>? <-the length of our netmask 01000000

So put everything together and we get

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|   <msg-type>  |<msg-semantics>|          <msg-size>           |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|  <tlv-length> (block)         |  <num-addr>   |<adr-semantics>|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| <tail-length> |                                               |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|                          <mid>                                |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|               |      <tlv length>(block)      |   <tlv-type>  |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|<tlv-semantics>| <index-start> |    <length>   |   <value>     |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MANEMO_TYPE   |    11110000   |            24 (dec)           |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|               0               |       1       |    10100000   |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|      8  (dec) |                                               |
	+-+-+-+-+-+-+-+-+                                               +
	|                   2001:471:1f11:246 (hex)                     |
	+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|               |            5 (dec)            | PREFIX_LENGTH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|   00010000    |       0       |       1       |   64 (dec)    |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As you can see there is overhead from the most efficent way you could send
one ipv6 address and its netmask size.  However this method would allow for
more addresses of similar prefixes to be added with less and less percent
overhead as more addresses are added to the address block.  I hope this was
helpful as an exercise and that it is taken as an only an example of how
something could be done with packetbb as I am sure there are other ways as
well. There could also be mistakes as well.

I also just wanted to point out that the complexity vs. overhead vs.
flexability is an issue we have tried to put a lot of thought into.  Echoing
Thomas I think we are just about where we want to be balancing all three.
(with the exception of the possible optional extened type field for both
tlv's and message types)

Justin Dean

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 11:50 AM
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB

> I'm afraid I don't have time to comment on this.

Thanks, I request MANET community to comment on that PAcketBB encoding of
the IPv6 Mobile Network PRefix - thank you.

> Padding occurs (optionally) only after a packet header or a message.

> Also see Thomas's comments.

I hope someone can comment on this packet format: ok or not ok, how should I
encode it better?

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Jun 2007 11:31:29 +0200

Justin Dean wrote:
> Here is a quick attempt of at an example packet looking to do what I
> think you are wanting to do. Sample IPv6 values used
> addr=2001:471:1f11:246:: prefix=64
[...]
> So put everything together and we get

Thanks for this picture, I will include it in my description as a way
PacketBB encodes an IPv6 Mobile Network Prefix.

> As you can see there is overhead from the most efficent way you could
> send one ipv6 address and its netmask size.  However this method
> would allow for more addresses of similar prefixes to be added with
> less and less percent overhead as more addresses are added to the
> address block.

Yes, I agree, and the degree of overhead reduction (compared to full
encoding) depends also on the number of common most significant bits
these addresses have (intuitively, the more common most significant bits
the less overhead).

> I hope this was helpful as an exercise and that it is taken as an
> only an example of how something could be done with packetbb as I am
> sure there are other ways as well. There could also be mistakes as
> well.

I will take it as the best suggestion as of now, thank you.

Alex