Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC

From: Wes Beebee <[email-masked]>
Date: Mon, 02 Aug 2010 09:07:11 -0400

One of the problems I have with this draft is that I don¹t think all of the
hardware platforms necessarily will support it in hardware.  Saying, ³oh
well, it¹s a layer violation², is not good enough  we routinely look at the
ethertype (in the L2 header) of the packet and match it up with the L3
header to prevent bogus packets from exercising paths in the router that can
lead to crashes.  This is called
³sanity check², and it is used for both security and stability reasons.
Just because the RP doesn¹t do this kind of check (presumably for
performance/layering reasons), doesn¹t mean that the check isn¹t being done
in hardware.   Good luck trying to get the hardware teams to upgrade their
hardware...

- Wes 

On 7/31/10 1:54 AM, "Fred Baker" <[email-masked]> wrote:

> This is to initiate a two week working group last call of
> draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits
> (spelling errors, minor suggested wording changes, etc), comment to the
> authors; if you find greater issues, such as disagreeing with a statement or
> finding additional issues that need to be addressed, please post your comments
> to the combined lists.
> 
> We are looking specifically for comments on the importance of the document as
> well as its content. If you have read the document and believe it to be of
> operational utility, that is also an important comment to make.
>  
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 02 Aug 2010 16:10:21 +0200

On 02/08/2010 15:07, "Wes Beebee" <[email-masked]> wrote:

> hardware platforms necessarily will support it in hardware.  Saying, ³oh well,
> it¹s a layer violation², is not good enough  we routinely look at the
> ethertype (in the L2 header) of the packet and match it up with the L3 header
> to prevent bogus packets from exercising paths in the router that can lead to
> crashes.  This is called
> ³sanity check², and it is used for both security and stability reasons.  Just
> because the RP doesn¹t do this kind of check (presumably for
> performance/layering reasons), doesn¹t mean that the check isn¹t being done in
> hardware.   Good luck trying to get the hardware teams to upgrade their
> hardware...
> 
> Woj> It¹s useful to point out that such a check is done based on L2/L3 source
> addresses, NOT destination. As per the other thread, we¹d be interested to
> hear of documented cases where such L2/L3 destination checking is used for
> mcast. We have not found any.
> 
> -Woj.
> 
> - Wes 
> 
> 
>> finding additional issues that need to be addressed, please post your
>> comments to the combined lists.
>>

---

From: Wes Beebee <[email-masked]>
Date: Mon, 02 Aug 2010 12:30:47 -0400

In case people haven¹t had time to read the whole draft, the key standards
track change to existing RFC¹s is:

³An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast
 message containing a multicast destination address in the IPv6
 header, but with a unicast destination address in the link-layer
 header, withstanding all other validity considerations as
 specified in the relevant IPv6 standards specifications.²

³An IPv6 sender node MAY choose to transmit an IPv6 multicast
 message as a link-layer unicast message.²

- Wes

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Aug 2010 20:09:13 +0200

Can you point us to the text in RFC 3810 that says "an IPv6 Receiver Node SHOULD drop..." and "...MAY NOT..."?

The paragraphs in RFC 3810 that contain the word "unicast" read:

   o  "source list" is an unordered list of zero or more unicast
      addresses from which multicast reception is desired or not
      desired, depending on the filter mode.  An implementation MAY
      impose a limit on the size of source lists.  When an operation
      causes the source list size limit to be exceeded, the service
      interface SHOULD return an error.

   The Source Address [i] fields are a vector of n unicast addresses,
   where n is the value in the Number of Sources (N) field.

   In MLDv2, General Queries are sent to the link-scope all-nodes
   multicast address (FF02::1).  Multicast Address Specific and
   Multicast Address and Source Specific Queries are sent with an IP
   destination address equal to the multicast address of interest.
   *However*, a node MUST accept and process any Query whose IP
   Destination Address field contains *any* of the addresses (unicast or
   multicast) assigned to the interface on which the Query arrives. This
   might be useful, e.g., for debugging purposes.

   The Source Address [i] fields are a vector of n unicast addresses,
   where n is the value in this record's Number of Sources (N) field.

   Version 2 Multicast Listener Reports are sent with an IP destination
   address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
   routers listen (see section 11 for IANA considerations related to
   this special destination address).  A node that operates in version 1
   compatibility mode (see details in section 8) sends version 1 Reports
   to the multicast address specified in the Multicast Address field of
   the Report.  In addition, a node MUST accept and process any version
   1 Report whose IP Destination Address field contains *any* of the
   IPv6 addresses (unicast or multicast) assigned to the interface on
   which the Report arrives.  This might be useful, e.g., for debugging
   purposes.

What you are arguing is that a statement which is not made in the RFC is normative in the way you interpret it, and making a statement that disagrees with your preconception but disagrees with no statement actually made in the RFC is a protocol error. As I read it, RFC 3810 doesn't normally expect it (for obvious reasons) but doesn't preclude it. This memo commits the egregious sin of making the statement and specifying the cases in which it is argued to be appropriate.

On Aug 2, 2010, at 6:30 PM, Wes Beebee wrote:

> In case people haven’t had time to read the whole draft, the key standards track change to existing RFC’s is:
> 
> “An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast 
>  specified in the relevant IPv6 standards specifications.”
> 
> “An IPv6 sender node MAY choose to transmit an IPv6 multicast
>  message as a link-layer unicast message.”
> 
> - Wes
> 
>> This is to initiate a two week working group last call of draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the combined lists.
>> 
>> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
>> 
>> 

http://www.ipinc.net/IPv4.GIF

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 2 Aug 2010 15:24:44 -0500

Sri and other authors,

Could you please note that the key change in your document is what Wes
has emailed today to us.   However, I am puzzled by the normative text
in your document for the key change.  If a host decides to transmit an
IPv6 multicast message as a link-layer unicast message, then as per your
receiver specification, a receiver is still legal to drop such a
message.   All you have is a "SHOULD NOT drop" which an implementation
can still not adhere to and drop the message.  If the receiver drops
this doctored multicast message, then your goal is not even met.   I
think only a "MUST NOT drop" meets your needs.    It would be good to
articulate what set of problems are we trying to solve and then we will
see what solutions are needed including any changes to existing RFC's.
I have already asked once in the mailer for what specifications exist in
the IETF that document the problem cases enumerated by DSL folks or
wireless LAN folks.

Thanks,

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Beebee (wbeebee)
Sent: Monday, August 02, 2010 12:31 PM
To: Fred Baker (fred); IPv6 Operations; 6man Mailing List
Cc: Kurt Erik Lindqvist
Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC

In case people haven't had time to read the whole draft, the key
standards track change to existing RFC's is:

"An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast 
 message containing a multicast destination address in the IPv6
 header, but with a unicast destination address in the link-layer
 header, withstanding all other validity considerations as
 specified in the relevant IPv6 standards specifications."

"An IPv6 sender node MAY choose to transmit an IPv6 multicast
 message as a link-layer unicast message."

- Wes

This is to initiate a two week working group last call of
draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed, please
post your comments to the combined lists.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

________________________________

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Aug 2010 08:54:03 -0500

Fred,

Snipped from RFC 3810, section 7 is the following text.

[For each interface over which the router operates the MLD protocol, the
router must configure that interface to listen to all link-layer
multicast addresses that can be generated by IPv6 multicasts.  For
example, an Ethernet-attached router must set its Ethernet address
reception filter to accept all Ethernet multicast addresses that start
with the hexadecimal value 3333 [RFC2464]; in the case of an Ethernet
interface that does not support the filtering of such a multicast
address range, it must be configured to accept ALL Ethernet multicast
addresses, in order to meet the requirements of MLD.]
	
I can program such a L2 multicast filter in the CAM (Content Addressable
Memory) of Ethernet hardware with CAM.  So if this router directly
receives a multicast message with multicast destination but unicast L2,
the sniffing on 3333.xxxx.xxxx fails to capture this packet and the
router just failed MLDv2 gleaning of this message.  One may also note
that MLD is used by ND as specified in RFC 4862 and RFC 4861.

So what text do we add to the Sri document to exclude MLDv2 protocol
from their proposal?  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred Baker (fred)
Sent: Monday, August 02, 2010 2:09 PM
To: Wes Beebee (wbeebee)
Cc: IPv6 Operations; 6man Mailing List; Kurt Erik Lindqvist
Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC

Can you point us to the text in RFC 3810 that says "an IPv6 Receiver
Node SHOULD drop..." and "...MAY NOT..."?

What you are arguing is that a statement which is not made in the RFC is
normative in the way you interpret it, and making a statement that
disagrees with your preconception but disagrees with no statement
actually made in the RFC is a protocol error. As I read it, RFC 3810
doesn't normally expect it (for obvious reasons) but doesn't preclude
it. This memo commits the egregious sin of making the statement and
specifying the cases in which it is argued to be appropriate.

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Aug 2010 16:01:14 +0200

Let me see if I understand you correctly. You would receive the L2 Multicast because your CAM contains the address, but you would not receive a message sent to the system's L2 unicast address. Why? Most ethernet chips I'm aware of will happily store any message they receive that is directed to their configured unicast address...

---

From: Stig Venaas <[email-masked]>
Date: Wed, 04 Aug 2010 04:53:08 -0700

I think this is a good document, and that it is ready,

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Aug 2010 09:11:23 -0700 (PDT)

I think this draft has some operational utility and therefore support its 
adoption as WG draft.

Regards,

Behcet

>
>From: Fred Baker <[email-masked]>
>To: IPv6 Operations <[email-masked]>; 6man Mailing List <[email-masked]>
>Cc: Kurt Erik Lindqvist <[email-masked]>
>Sent: Sat, July 31, 2010 12:54:27 AM
>Subject: draft-gundavelli-v6ops-l2-unicast WGLC
>
>
>(spelling errors, minor suggested wording changes, etc), comment to the authors; 
>if you find greater issues, such as disagreeing with a statement or finding 
>additional issues that need to be addressed, please post your comments to the 
>combined lists.
>
>

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 12 Aug 2010 18:30:57 +0200

Hi,

I support the adoption of this document as WG draft.
The described solution is used in the proposal "Duplicate Address
Detection Proxy"
(http://tools.ietf.org/html/draft-costa-6man-dad-proxy-00) to avoid
multicasted messages (i.e. flooding) in a VLAN.

Best regards.

JMC.

2010/7/31 Fred Baker <[email-masked]>:
> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 18:52:23 -0500

I have made my points for pitfalls related to the rules of this
document.  However, since the new rules in this document have a language
of SHOULD NOT drop for receive and MAY for transmit, I don't see any
MUST language in the rules.  The only MUST in the rules section is a
MUST to apply such additional considerations where the actual
considerations have no MUST.  Thus if my hardware chooses to ignore the
receive and transmit rules of this document and comply to RFC 2464, my
hardware does not violate this document.  Therefore, I support this
document.

However, before we forward this document to the IESG, could we please
make some minor changes to text.  One change is suggested below.

OLD TEXT

[An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message
containing a multicast destination address in the IPv6 header, but with
a unicast destination address in the link-layer header, withstanding all
other validity considerations as specified in the relevant IPv6
standards specifications. ]

NEW TEXT

[An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message
containing a multicast destination address in the IPv6 header, but with
a unicast destination address in the link-layer header.]

The reason is the use of word "relevant" in old text which appears loose
to me because folks may question, well, which specific IPv6 standards
specifications and the discussion protracts.

I have other minor text changes to propose that I couldn't get to today.
I hope to get to the other suggestions early next week.

Hemant