Skip to main content

MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
draft-melsen-mac-forced-fwd-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-melsen-mac-forced-fwd-05.txt 

The IESG has no problem with the publication of 'MAC-Forced Forwarding: A 
Method for Traffic Separation on an Ethernet Access Network' 
<draft-melsen-mac-forced-fwd-05.txt> as an Informational RFC. 

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11306&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melsen-mac-forced-fwd-05.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Ballot Text

Technical Summary
 
This document describes a mechanism to ensure layer-2 separation of
LAN stations accessing an IPv4 gateway over a shared Ethernet
segment. Rather than use standard "bridge" forwarding, this document
uses a variant of ARP spoofing and address filtering to prevent nodes
from improperly sending traffic directly to a MAC address other than
that of the designated Access Router.
 
Working Group Summary
 
This document is not a Working Group document and has not been
discussed in any WG.
 
Protocol Quality
 
This document has been reviewed for the IESG by Thomas Narten.

IESG Note

The IESG had serious concerns about an earlier version of
this document with respect to its affect on IPv6 and VRRP.
The authors chose to make significant efforts to correct the
document based on these concerns. The latest version (-04,
published Jan 27) is now satisfactory.

This RFC is not a candidate for any level of Internet Standard.  The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols.  The RFC Editor
has chosen to publish this document at its discretion.  Readers of
this document should exercise caution in evaluating its value for
implementation and deployment.  See RFC 3932 for more information.

RFC Editor Note