Subject: [6lowpan] ND-17

From: Tom <[email-masked]>
Date: Mon, 16 Jan 2012 21:57:51 +0530

Hi All,

Kindly clarify:

1) Section 5.3 demands "In all cases the RS retransmissions are terminated
when a RA is received."
Is this also applicable when a RA is received with router lifetime is set
to zero (e.g a router going down as suggested in rfc4861).

2) TBD4 number (155 XXX) conflicts with the one allocated for RPL.
Is there a other suggested value or one under common agreement outside
ND-17 used for interoperability.

3) Believe there is a typo here? (page 49, section 12)
o TBD3 = 33
o TBD4 = 155 XXX
o TBD3 = 156 XXX -> Believe this is a typo.

Regards,
Tom

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jan 2012 18:40:25 +0100

Hi Tom,

(WG chair hat off, individual WG member hat on:)

> 1) Section 5.3 demands "In all cases the RS retransmissions are terminated when a RA is received."
> Is this also applicable when a RA is received with router lifetime is set to zero (e.g a router going down as suggested in rfc4861).

Well, you could consider it to be, but because of the lifetime it then restarts right after 0 seconds…
Yes, something like this could be spelled out.

> Is there a other suggested value or one under common agreement outside ND-17 used for interoperability. 

The same is true for TBD1 (31) and TBD2 (32), which have been assigned in the meantime:
31      DNS Search List Option                  [RFC6106]
32      Proxy Signature (PS)                    [RFC-ietf-csi-proxy-send-05.txt]

These should be relatively painless, but 155 might hurt in interop testing.
Good question, I'll defer to the interop testing community.

> o TBD3 = 156 XXX -> Believe this is a typo. 

Yes, this is a typo; this should be TBD5.

The numbering of course will be solved once we have actual IANA assignments.
Depending on when the spec approval happens, 33 and 156 may also go to other protocols in the meantime.

I believe we could go for an RFC4020 style early allocation if this uncertainty creates hardships.

Two other observations:
-- we are at ND-18 already.  Please always use the most recent I-D, available at:

    http://tools.ietf.org/html/draft-ietf-6lowpan-nd

(and now finally with WG chair hat:)

-- please indicate your name on your mailing list messages (I'm assuming that Tom is not your only name, which of course could be the case in several locales).

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 26 Jan 2012 15:35:45 +0000

> 32      Proxy Signature (PS)                    [RFC-ietf-csi-proxy-send-05.txt]

#31 triggered me: should 6lowpan-ND mention anything about support of the RDNSS option in RFC6106? Supporting would allow 6LBR/6LRs to e.g. distribute an address of a DNS server to all 6LNs. Or are there better alternatives for a 6LN to obtain a DNS server? In many use cases DNS is an essential service component, see. e.g. draft-vanderstok-core-bc-05.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday 16 January 2012 18:40
To: Tom
Cc: [email-masked]
Subject: Re: [6lowpan] ND-17

Hi Tom,

> Is this also applicable when a RA is received with router lifetime is set to zero (e.g a router going down as suggested in rfc4861).

Well, you could consider it to be, but because of the lifetime it then restarts right after 0 seconds...
Yes, something like this could be spelled out.

Two other observations:

Grüße, Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2012 18:24:36 +0100

On Jan 26, 2012, at 16:35, Dijk, Esko wrote:

> #31 triggered me: should 6lowpan-ND mention anything about support of the RDNSS option in RFC6106?

I don't think so, from my point of view the two are orthogonal (i.e., 6LoWPAN neither excludes nor optimizes RDNSSO).

(But maybe the way 6LoWPAN-ND and the other ND options fit together is a nice subject for a section in the LWIG guidance document.)

> Supporting would allow 6LBR/6LRs to e.g. distribute an address of a DNS server to all 6LNs. Or are there better alternatives for a 6LN to obtain a DNS server? In many use cases DNS is an essential service component, see. e.g. draft-vanderstok-core-bc-05.

*If* your 6LoWPAN nodes need a DNS server, they should get it either using RDNSSO (and, heaven forbid, DNSSLO) or, if they are already using DHCPv6 for other reasons, using that.
(We at least used to have a sizable group of DHCPv6 fans in the 6LoWPAN WG, so I'm not sure we can really recommend either.)

Grüße, Carsten