Subject: [6lowpan] #46: M-bit in the RA

From: "6lowpan issue tracker" <[email-masked]>
Date: Mon, 03 Aug 2009 12:52:35 -0000

#46: M-bit in the RA
--------------------------------+-------------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement         |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  nd                  |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------
 nd-04 currently redefines the use of the M "Managed" bit to indicate that
 this router is an ER or has an ER available through it. Several people has
 found this confusing and would like to keep the original DHCPv6 managed
 indication for M.

 This ticket is to change M back to its original meaning (DHCPv6
 available). The availability of an ER will instead be encoded into the Prf
 field. The new Prf field encoding would be:

 "LoWPAN Routers with no ER available SHOULD set Prf to (00) for low
 preference, LoWPAN Routers with ER availability SHOULD set Prf to (01) for
 normal preference, and LoWPAN Edge Routers SHOULD set Prf to (01) for high
 preference."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Aug 2009 17:09:02 +0200

Make that:

> "LoWPAN Routers with no ER available SHOULD set Prf to (11) for low
> preference, LoWPAN Routers with ER availability SHOULD set Prf to  
> (00) for

Prf is a two-bit signed (two's complement) field.
11 = -1.
00 = 0.
01 = 1.
(10 = 2. is reserved in RFC 4191 -- we could start to use it if  
needed, though.)

I haven't thought through whether SHOULD is the right level of  
requirement here.
(Intuitively, I'd say MUST, because I can imagine the protocol  
seriously misbehaving without.)

(Maybe it would also be good to add a short note that, while the M and  
O bits are available, they are not very useful in a 6LoWPAN.)

Gruesse, Carsten

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Tue, 04 Aug 2009 07:56:55 -0000

#46: M-bit in the RA
 Severity:  -                   |   Resolution:                    
 Keywords:                      |  

Comment(by [email-masked]):

 Fix from Carsten:

 Prf is a two-bit signed (two's complement) field.
 11 = -1.
 00 = 0.
 01 = 1.
 (10 = 2. is reserved in RFC 4191 -- we could start to use it if needed,
 though.)

 I haven't thought through whether SHOULD is the right level of requirement
 here.
 (Intuitively, I'd say MUST, because I can imagine the protocol seriously
 misbehaving without.)

 (Maybe it would also be good to add a short note that, while the M and O
 bits are available, they are not very useful in a 6LoWPAN.)

 Gruesse, Carsten

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Mon, 17 Aug 2009 15:19:13 -0000

#46: M-bit in the RA
--------------------------------+-------------------------------------------
 Reporter:  [email-masked]  |        Owner:  [email-masked]
     Type:  enhancement         |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  nd                  |      Version:                    
 Severity:  -                   |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Done in nd-05.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46#comment:2>
6lowpan <http://tools.ietf.org/6lowpan/>