Subject: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt?

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 12:24:44 +0000

This is a DHCPv6 option for carrying IPv4-Embedded multicast and unicast IPv6 prefixes.   The DHC working group should review this document for correctness with respect to the DHCP option specification.   Can I get a few volunteers to give this a careful read to make sure the DHCP specification language is correct?

Begin forwarded message:
> From: <[email-masked]>
> Subject: Re: [Softwires] I-D Action:	draft-ietf-softwire-multicast-prefix-option-02.txt
> Date: October 18, 2012 1:37:48 AM EDT
> 
> We believe this version is ready for a WGLC.
> 
> Cheers,
> Med
> 
> 
>> -----Message d'origine-----
>> De : [email-masked] 
>> [mailto:[email-masked]] De la part de 
>> [email-masked]
>> Envoyé : mardi 16 octobre 2012 17:03
>> À : [email-masked]
>> Cc : [email-masked]
>> Objet : [Softwires] I-D Action: 
>> draft-ietf-softwire-multicast-prefix-option-02.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line 
>> Internet-Drafts directories.
>> This draft is a work item of the Softwires Working Group of the IETF.
>> 
>> 	Title           : DHCPv6 Option for IPv4-Embedded 
>> Multicast and Unicast IPv6 Prefixes
>> 	Author(s)       : Mohamed Boucadair
>>                         Jacni Qin
>>                         Tina Tsou
>>                         Xiaohong Deng
>> 	Filename        : 
>> draft-ietf-softwire-multicast-prefix-option-02.txt
>> 	Pages           : 7
>> 	Date            : 2012-10-16
>> 
>> Abstract:
>>  This document defines Dynamic Host Configuration Protocol version 6
>>  (DHCPv6) Option for multicast transition solutions, aiming to convey
>>  the IPv6 prefixes to be used to build unicast and multicast IPv4-
>>  embedded IPv6 addresses.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast-
>> prefix-option
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix
>> -option-02
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-multicast-
>> prefix-option-02
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 18 Oct 2012 12:33:35 +0000

Could we PLEASE not have yet another encoding format for prefixes.

And why is a 12 octet field called ...64??? 12x8 = 96 last time I checked my slide rule?

The prefix should either be encoded as a full 128 bits (16 octets) OR using the minimal encoding format (i.e., variable length with enough octets to handle the number of bits in the prefix - (prefix length + 7) / 8). I don't really care which, but please do not add a third format.

- Bernie

Sent from my iPad

On Oct 18, 2012, at 8:24 AM, "Ted Lemon" <[email-masked]> wrote:

> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 18 Oct 2012 13:26:50 +0000

For the variable length encoding example see http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05.

We also used this in v4 for classless static route option (http://tools.ietf.org/html/rfc3442).

Regarding:

* ASM_PREFIX64 and SSM_PREFIX64 are /96

This doesn't make sense. Why is 64 in the name when this is 96? Isn't that very confusing? Why not drop the "64" from the name as these are obviously variable length prefixes (given that they have prefix length). Perhaps these are a softwire standard name, but it seems to be a badly chosen one to me.

Regarding the encoding/diagram, you should use:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        OPTION_PREFIX64        |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  asm-length   |                                               |
     +-+-+-+-+-+-+-+-+                                               :
     :                  ASM_PREFIX (VARIABLE octets)                     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  ssm-length   |                                               |
     +-+-+-+-+-+-+-+-+                                               :
     :                  SSM_PREFIX (VARIABLE octets)                     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | unicast-length|                                               |
     +-+-+-+-+-+-+-+-+                                               :
     :                   U_PREFIX (VARIABLE octets)                      :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The *-length field determine how long each field is - it is <prefix length>+7/8 octets (i.e., it specifies the maximum number of octets required to hold the prefix). Note that the option-length is 3 + ((asm-length+7)/8) + ((ssm-length+7)/8) + ((unicast-length+7)/8).

I'd also clean up the asm-length (and other length) description to something like:

   asm-length:  the prefix-length for the ASM IPv4-embedded prefix, as
        an 8-bit unsigned integer (0 to 128).  This field represents the
        number of valid leading bits in the prefix.
   ASM_PREFIX:  this field identifies the IPv6 multicast prefix to be
       used to synthesize the IPv4-embedded IPv6 addresses of the
       multicast groups. It is a variable size field with the length of
       the field defined by the asm-length field and is rounded up to
       the nearest octet boundary (if case when asm-length is not
      divisible by 8).  In such case any additional padding bits must
      be zeroed.

(And similar changes for the others.)

Or, if you don't want the complexity of variable length fields, please use 16 octet fields for the prefix, not 12 octet. The reason for this is that this is yet another encoding format that servers, clients, and packet decoders would need to be support and just makes adoption of the option much more difficult as implementations need to support this new encoding format (unless of course you want people to enter the 'binary' (hex) values for the option data - which is likely not a good idea).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 18, 2012 8:50 AM
To: Bernie Volz (volz)
Cc: Ted Lemon
Subject: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt?
Importance: High

Dear Bernie,

As I'm not sure I understand your comment, I prefer to send you this message offline. I will send an answer to the list latter.

Below some clarification for the length of these prefixes:

* ASM_PREFIX64 and SSM_PREFIX64 are /96
* U_PREFIX64 is a prefix with variable length; the maximum length is /96

Could you please let me know what is wrong with this text:

   asm-length:  the length for the ASM IPv4-emebdded IPv6 prefix in
      bits.  If the field is set to 0, all bits of ASM_PREFIX64 field
      MUST be set to zeros.
   ASM_PREFIX64:  this field identifies the IPv6 multicast prefix to be
      used to synthesize the IPv4-embedded IPv6 addresses of the
      multicast groups.  The conveyed multicast IPv6 prefix MUST belong
      to the ASM range.
   ssm-length:  the length for the SSM IPv4-emebdded IPv6 prefix in
      bits.  If the field is set to 0, all bits of SSM_PREFIX64 field
      MUST be set to zeros.
   SSM_PREFIX64:  this field identifies the IPv6 multicast prefix to be
      used to synthesize the IPv4-embedded IPv6 addresses of the
      multicast groups.  The conveyed multicast IPv6 prefix MUST belong
      to the SSM range.
   unicast-length:  the length for the unicast IPv4-emebdded IPv6 prefix
      in bits.  If the field is set to 0, all bits of U_PREFIX64 field
      MUST be set to zeros.
   U_PREFIX64:  this field identifies the IPv6 unicast prefix to be used
      in SSM mode for constructing the IPv4-embedded IPv6 addresses of
      the multicast sources.  It may also be used to extract the IPv4
      address from the received multicast data flows.  The address
      mapping MUST follow the guidelines documented in [RFC6052].

Or you are referring to the figure?

Thanks.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part 
>de Bernie Volz (volz) Envoyé : jeudi 18 octobre 2012 14:34 À : Ted 
>Lemon Cc : [email-masked]; <[email-masked]> WG Objet : Re: 
>[dhcwg] Volunteers to review 
>draft-ietf-softwire-multicast-prefix-option-02.txt?
>
>The prefix should either be encoded as a full 128 bits (16
>octets) OR using the minimal encoding format (i.e., variable length 
>with enough octets to handle the number of bits in the prefix - (prefix 
>length + 7) / 8). I don't really care which, but please do not add a 
>third format.
>
>- Bernie
>
>Sent from my iPad
>
>> This is a DHCPv6 option for carrying IPv4-Embedded multicast
>and unicast IPv6 prefixes.   The DHC working group should 
>review this document for correctness with respect to the DHCP 
>option specification.   Can I get a few volunteers to give 
>this a careful read to make sure the DHCP specification language is 
>correct?
>> 
>> Begin forwarded message:
>>> Subject: Re: [Softwires] I-D Action:    
>>>> [email-masked] Envoyé : mardi 16 octobre 2012 17:03 À : 
>>>> [email-masked] Cc : [email-masked] Objet : [Softwires] 
>>>> I-D Action:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.

---

From: <[email-masked]>
Date: Thu, 18 Oct 2012 15:42:25 +0200

Re-,

Please see inline. 

Cheers,
Med 

>De : Bernie Volz (volz) [mailto:[email-masked]] 
>Envoyé : jeudi 18 octobre 2012 15:27
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Cc : Ted Lemon
>Objet : RE: OFFLIST RE: [dhcwg] Volunteers to review 
>For the variable length encoding example see 
>http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05.
>

Med: Thanks for the pointers. I'm aware of these documents. 

>This doesn't make sense.

Med: What does not make sense? These are specific prefixes which are provisioned to build a multicast IPv6 address embedding an IPv4 address in the last 32 bits. The recommended length for these prefixes is /96. 

 Why is 64 in the name when this is 
>96? Isn't that very confusing? 

Med: 64 is there because these prefixes are used for IPv4-IPv6 multicast interconnection. 

Why not drop the "64" from the 
>name as these are obviously variable length prefixes (given 
>that they have prefix length). Perhaps these are a softwire 
>standard name, but it seems to be a badly chosen one to me.

Med: PREFIX64 is widely used in IPv4/IPv6 interconnection matters. 

>The *-length field determine how long each field is - it is 
><prefix length>+7/8 octets (i.e., it specifies the maximum 
>number of octets required to hold the prefix). Note that the 
>option-length is 3 + ((asm-length+7)/8) + ((ssm-length+7)/8) + 
>((unicast-length+7)/8).
>
>Or, if you don't want the complexity of variable length 
>fields, please use 16 octet fields for the prefix, not 12 
>octet. The reason for this is that this is yet another 
>encoding format that servers, clients, and packet decoders 
>would need to be support and just makes adoption of the option 
>much more difficult as implementations need to support this 
>new encoding format (unless of course you want people to enter 
>the 'binary' (hex) values for the option data - which is 
>likely not a good idea).
>
>- Bernie
>
>Subject: OFFLIST RE: [dhcwg] Volunteers to review 
>As I'm not sure I understand your comment, I prefer to send 
>you this message offline. I will send an answer to the list latter.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 18 Oct 2012 13:51:33 +0000

Perhaps we should consider updating draft-ietf-dhc-option-guidelines to include a section on IPv6 prefixes?

5.x Option with IPv6 prefixes

   There are two formats that should be used for IPv6 prefixes.

   One format is a 8-bit prefix length field followed by a fixed
   16-octet (128-bit) prefix. An example of this encoding is the
   IAPREFIX option (see RFC 3633).

   The other format is a 8-bit prefix length field followed by a
   variable length, 0 to 16, octet field contain the required prefix
   bits. The length is rounded up to the nearest octet boundary
   (if case when prefix length is not divisible by 8).  In such case
   any additional padding bits must be zeroed. [Not sure if we
   have an RFC yet that shows an example of this encoding.]

   While the first format is simpler to use, the second format is
   (now) slightly more preferred as it reduces the option and
   packet size.

Note that comment about preference might be something to be debated.

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Thursday, October 18, 2012 9:27 AM
To: [email-masked]'; [email-masked]
Cc: Ted Lemon
Subject: RE: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt?

Regarding:

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 18, 2012 8:50 AM
To: Bernie Volz (volz)
Cc: Ted Lemon
Subject: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt?
Importance: High

Dear Bernie,

Thanks.

Cheers,
Med