Subject: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

From: Christian Vogt <[email-masked]>
Date: Mon, 9 Nov 2009 05:44:48 -0500

Folks -

During the SAVI working group meeting today, we made a consensus check
about adopting Internet draft "draft-bi-savi-dhcp-00" as a working group
document, showing a clear majority of attendees in favor.  I would now
like to initiate a confirming consensus call here on the mailing list.

Please answer the following question with either "yes" or "no":

   Should the SAVI working group adopt Internet draft
   "draft-bi-savi-dhcp-00" as a starting point for the SAVI protocol
   specification for DHCP-assigned IP addresses?

Please respond before Friday, November 20.  I am attaching Internet
draft "draft-bi-savi-dhcp-00" for your convenience.

- Christian

---

From: Mark Williams <[email-masked]>
Date: Mon, 09 Nov 2009 19:09:13 +0800

Yes

Mark

On 9/11/2009 6:44 PM, Christian Vogt wrote:
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Nov 2009 08:23:17 -0500

Yes, the working group should adopt this document as the starting point 
for our work on this topic.

Yours,
Joel M. Halpern

Christian Vogt wrote:
> ------------------------------------------------------------------------
>

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Nov 2009 09:37:30 -0600

Hi Christian

I am fine with adopting this document as a WG draft.

However, this draft,  imho, is limited when applying
for public access networks, especially broadband networks.

I would like to ask WG to  consider to adopt
DHCP-PD based solution  as a compliment.
http://tools.ietf.org/id/draft-kaippallimalil-savi-dhcp-pd-00.txt

BR
Frank

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>
Sent: Monday, November 09, 2009 4:44 AM
Subject: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

Folks -

- Christian

--------------------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Nov 2009 17:11:17 -0500

You make a good argument in your draft that we need to support SAVI 
applied to prefixes delegated with DHCP to CPE rotuers.

If we do need to handle it, I would ask that we still have only one 
document that describes DHCP handling.  This would include describing 
how the SAVI devices knows which mode is applicable (either by 
configuration or by sniffing, if that is effective.)

I think it would do the group a disservice, and confuse readers, if we 
had two different DHCP documents for different cases.

Yours,
Joel

Frank Xia wrote:
> ----- Original Message ----- From: "Christian Vogt" 
> <[email-masked]>

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Nov 2009 16:43:20 -0600

Hi Joel

Thank your comments.
Please see my response.

BR
Frank

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Monday, November 09, 2009 4:11 PM
Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

> applied to prefixes delegated with DHCP to CPE rotuers.
Frank=>Thank you. This is a real deployment scenario for public
access network.

> document that describes DHCP handling.  This would include describing how 
> the SAVI devices knows which mode is applicable (either by configuration 
> or by sniffing, if that is effective.)
Frank=>It is a little bit difficult to fit these two into one document.
First of all, there are architctural difference. Secondly, if you look
into the details of Bi's document,  the whole state machine is not
applicable to the scenario we mention.  The reasons are CPE acting
as a router terminates all ARP/DAD messages, and DHCP messages
(RFC3315) are different from DHCP-PD (RFC3633).

>
> I think it would do the group a disservice, and confuse readers, if we had 
> two different DHCP documents for different cases.
Frank=>We can document the relationship between the two documents.
We can also try to keep these document consistent in style.

---

From: John Kaippallimalil <[email-masked]>
Date: Mon, 09 Nov 2009 17:02:51 -0600

Yes.

John K.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Vogt
Sent: Monday, November 09, 2009 4:45 AM
To: SAVI Mailing List
Cc: Guang Yao
Subject: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

Folks -

During the SAVI working group meeting today, we made a consensus check about
adopting Internet draft "draft-bi-savi-dhcp-00" as a working group document,
showing a clear majority of attendees in favor.  I would now like to
initiate a confirming consensus call here on the mailing list.

Please respond before Friday, November 20.  I am attaching Internet draft
"draft-bi-savi-dhcp-00" for your convenience.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Nov 2009 00:25:51 +0100

I also support adopting this document as a WG item

Joel M. Halpern escribió:
> Yes, the working group should adopt this document as the starting 
> point for our work on this topic.
>
> Yours,
> Joel M. Halpern
>
> Christian Vogt wrote:
>> Folks -
>>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 10 Nov 2009 08:27:04 +0900

--------------------------------------------------
From: "Frank Xia" <[email-masked]>
Sent: Tuesday, November 10, 2009 7:43 AM
To: "Joel M. Halpern" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

> (RFC3315) are different from DHCP-PD (RFC3633).

Agree.
My consideration is that: in the most cases, the two documents will be 
implemented by different products (switch for Enterprise networks, campus 
networks vs.
devices for broadband networks). If we mixed both of them, it might
make the draft too complex, and the vendors will actually implement
different part of the mixed document.

> We can also try to keep these document consistent in style.

Joel raised a good question that we should not confuse readers.
I agree with Frank's suggestion. We'd like to collaborate with Frank Xia and 
John Kaippallimalil, the relationship could be considered as a part of the 
framework,
and we will work with them to keep these document consistent.

thanks,
Jun

---

From: Lin Tao <[email-masked]>
Date: Tue, 10 Nov 2009 09:39:40 +0800

Yes!

Yours'
Tao

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>
Sent: Monday, November 09, 2009 6:44 PM
Subject: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

Folks -

- Christian

---

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 10 Nov 2009 04:17:43 +0100

Yes, I agree.

Best regards.

JMC.

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 10 Nov 2009 09:01:11 +0100

Yes

Eric Levy-Abegnoli

---

From: Alberto García <[email-masked]>
Date: Tue, 10 Nov 2009 11:12:54 +0100

Yes,

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Christian Vogt
|  Enviado el: lunes, 09 de noviembre de 2009 11:45
|  Para: SAVI Mailing List
|  CC: Guang Yao
|  Asunto: [savi] Consensus call on adopting draft-bi-savi-dhcp-00
|  
|  Folks -
|  
|  During the SAVI working group meeting today, we made a consensus check
|  about adopting Internet draft "draft-bi-savi-dhcp-00" as a working group
|  document, showing a clear majority of attendees in favor.  I would now
|  like to initiate a confirming consensus call here on the mailing list.
|  
|  Please answer the following question with either "yes" or "no":
|  
|     Should the SAVI working group adopt Internet draft
|     "draft-bi-savi-dhcp-00" as a starting point for the SAVI protocol
|     specification for DHCP-assigned IP addresses?
|  
|  Please respond before Friday, November 20.  I am attaching Internet
|  draft "draft-bi-savi-dhcp-00" for your convenience.
|  
|  - Christian
|

---

From: Jianping Wu <[email-masked]>
Date: Wed, 11 Nov 2009 00:33:00 +0800

Yes, I support it becomes a WG item.

Jianping WU

Christian Vogt wrote:

>SAVI                                              J. Bi, J. Wu, G. Yao
>Internet Draft                                                 CERNET
>Intended status: Standard Tracks                             F. Baker
>Expires: May 2010                                               Cisco
>                                                      November 9, 2009
>
>
>
>                        SAVI Solution for DHCPv4/v6
>                         draft-bi-savi-dhcp-00.txt
>
>
>Status of this Memo
>
>   This Internet-Draft is submitted to IETF in full conformance with the
>   provisions of BCP 78 and BCP 79. This document may not be modified,
>   and derivative works of it may not be created, except to publish it
>   as an RFC and to translate it into languages other than English.
>
>   This document may contain material from IETF Documents or IETF
>   Contributions published or made publicly available before November 10,
>   2008. The person(s) controlling the copyright in some of this
>   material may not have granted the IETF Trust the right to allow
>   modifications of such material outside the IETF Standards Process.
>   Without obtaining an adequate license from the person(s) controlling
>   the copyright in such materials, this document may not be modified
>   outside the IETF Standards Process, and derivative works of it may
>   not be created outside the IETF Standards Process, except to format
>   it for publication as an RFC or to translate it into languages other
>   than English.
>
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF), its areas, and its working groups.  Note that
>   other groups may also distribute working documents as Internet-Drafts.
>
>   Internet-Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/ietf/1id-abstracts.txt
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html
>
>   This Internet-Draft will expire on May 9, 2010.
>
>
>
>
>Bi                      Expires May 9, 2010                  [Page 1]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>Copyright Notice
>
>   Copyright (c) 2009 IETF Trust and the persons identified as the
>   document authors. All rights reserved.
>
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents in effect on the date of
>   publication of this document (http://trustee.ietf.org/license-info).
>   Please review these documents carefully, as they describe your rights
>   and restrictions with respect to this document.
>
>Abstract
>
>   This document specifies the procedure for creating bindings between a
>   DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an
>   anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation
>   Improvements) device. The bindings can be used to filter packets with
>   forged IP addresses generated on the local link.
>
>Table of Contents
>
>
>   1. Introduction ................................................ 3
>   2. Conventions used in this document............................ 4
>   3. Mechanism Overview .......................................... 4
>   4. Background and Related Protocols............................. 4
>   5. Terminology ................................................. 5
>   6. Conceptual Data Structures................................... 5
>      6.1. Binding State Table (BST)............................... 5
>      6.2. Filtering Table (FT).................................... 5
>   7. Binding States Description................................... 6
>   8. DHCP Scenario ............................................... 6
>   9. Anchor Attributes ........................................... 7
>      9.1. SAVI-Host Attribute..................................... 7
>      9.2. SAVI-Poly Attribute..................................... 7
>      9.3. SAVI-DHCP-Trust Attribute............................... 7
>      9.4. SAVI-RA-Trust Attribute................................. 8
>      9.5. SAVI-SAVI Attribute..................................... 8
>   10. Prefix Configuration........................................ 8
>   11. Binding Set Up ............................................. 9
>      11.1. Process of DHCP Snooping............................... 9
>         11.1.1. Initialization.................................... 9
>            11.1.1.1. Trigger Event................................ 9
>            11.1.1.2. Message Validation........................... 9
>            11.1.1.3. Following Actions........................... 10
>         11.1.2. From START to LIVE............................... 10
>            11.1.2.1. Trigger Event............................... 10
>
>
>Bi                      Expires May 9, 2010                  [Page 2]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>            11.1.2.2. Message Validation.......................... 10
>            11.1.2.3. Following Actions........................... 10
>         11.1.3. From LIVE to DETECTION........................... 11
>            11.1.3.2. Message Validation.......................... 11
>            11.1.3.3. Following Actions........................... 12
>         11.1.4. From DETECTION to BOUND.......................... 12
>            11.1.4.1. Trigger Event............................... 12
>            11.1.4.2. Following Actions........................... 12
>         11.1.5. After BOUND...................................... 12
>      11.2. State Machine of DHCP Snooping ....................... 13
>   12. Filtering Specification.................................... 13
>      12.1. Filter Data Packet.................................... 13
>      12.2. Filter Control Packet................................. 14
>   13. Format and Delivery of Probe Messages ..................... 14
>   14. Data packet trigger on SAVI-Poly anchor ................... 15
>   15. Binding Remove ............................................ 16
>   16. Handle port DOWN event..................................... 16
>   17. About Collision in Detection............................... 16
>      17.1. Whether to notify the DHCP server .................... 16
>      17.2. The result of detection without host aware ........... 16
>   18. Filtering during detection................................. 17
>   19. Binding Number Limitation.................................. 17
>   20. MLD Consideration ......................................... 17
>   21. Constants ................................................. 17
>   22. Summary of to-be-removed sections and open issues ......... 18
>   23. Security Considerations.................................... 18
>   24. IANA Considerations........................................ 18
>   25. References ................................................ 18
>      25.1. Normative References.................................. 18
>      25.2. Informative References................................ 19
>   26. Acknowledgments ........................................... 19
>
>1. Introduction
>
>   This document describes the procedure for creating bindings between
>   DHCP assigned addresses and an anchor (refer to [savi-framework]).
>   Other related details about this procedure are also specified in this
>   document.
>
>   These bindings can be used to filter packets with forged IP addresses.
>   How to use these bindings is specified in [savi-framework], depending
>   on the environment and configuration. The definition and examples of
>   anchor is also specified in [savi-framework].
>
>   The binding process is inspired by the work of IP source guard. This
>   specification differs from IP source guard in the specification for
>
>
>
>Bi                      Expires May 9, 2010                  [Page 3]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   collision detection, which is quite useful in an environment with
>   multiple address assignment methods.
>
>2. Conventions used in this document
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
>3. Mechanism Overview
>
>   The mechanism specified in this document is designed to provide a
>   host level source IP address validation granularity, as a supplement
>   to BCP38 [BCP38]. This mechanism is deployed on the access device
>   (including access switch, wireless access point/controller, etc), and
>   performs mainly DHCPv4/v6 snooping to set up bindings between DHCP
>   assigned IP address and corresponding anchors. The bindings can be
>   used to validate the source address in the packets.
>
>4. Background and Related Protocols
>
>   This mechanism is an instance of a SAVI [savi-framework] solution,
>   specialized for addresses assigned using the DHCP protocol.
>
>   Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic
>   Host Configuration Protocol version 6 [RFC3315] specify the
>   procedures for providing a client with assigned address and other
>   configuration information from a DHCP server. If a client gets an
>   address through the DHCP protocol, the address should be regarded as
>   a potential "authorized" or "registered" address of the client.
>
>   In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as
>   another address assignment mechanism. A node can use this mechanism
>   to auto-configure an IPv6 address. A DHCPv6 client may use a
>   stateless address to send message to DHCP server. Even in a DHCPv6-
>   only environment, a node must assign its link-local address through
>   this mechanism. [RFC4862] also clearly requires that duplicated
>   address detection must be performed on any IPv6 address, including
>   DHCPv6 address.
>
>   [RFC4861] specifies the Neighbor Discovery protocol, which is an
>   essential part of IPv6 address assignment.
>
>   [RFC5227] specifies the procedure to detect IPv4 address collision.
>   It is not required currently. However, this feature is useful to
>   determine the uniqueness of an IPv4 address on the link.
>
>
>
>Bi                      Expires May 9, 2010                  [Page 4]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>5. Terminology
>
>   The terms used in this document are described in [savi-framework],
>   [RFC2131] and [RFC3315].
>
>6. Conceptual Data Structures
>
>   (To be removed and merged with data structures used by other
>   mechanisms in [savi-framework] if possible)
>
>   This section describes the possible conceptual data structures used
>   in this mechanism.
>
>   Two main data structures are used to record bindings and their states
>   respectively. There is redundancy between the two structures, for the
>   consideration of separation of data plane and control plane.
>
>6.1.  Binding State Table (BST)
>
>   This table contains the state of binding between source address and
>   anchor. Entries are keyed on the anchor and source IP address. Each
>   entry has a lifetime field recording the remaining lifetime of the
>   entry, a state field recording the state of the binding and a field
>   for recording other information.
>
>             +---------+----------+-------+-----------+-------+
>             | Anchor  | Address  | State | Lifetime  |Other  |
>             +---------+----------+-------+-----------+-------+
>             | A       | IP_1     | Bound |  65535    |       |
>             +---------+----------+-------+-----------+-------+
>             | A       | IP_2     | Bound |  10000    |       |
>             +---------+----------+-------+-----------+-------+
>             | B       | IP_3     |_Start |      1    |       |
>             +---------+----------+-------+-----------+-------+
>                         Figure 1 Instance of BST
>
>
>6.2.  Filtering Table (FT)
>
>   This table contains the bindings between anchor and address, keyed on
>   anchor. This table doesn't contain any state of the binding. This
>   table is only used to filter packets. An Access Control List can be
>   regarded as a practical instance of this table.
>
>
>
>
>
>
>Bi                      Expires May 9, 2010                  [Page 5]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>                          +---------+----------+
>                          |Anchor   |Address   |
>                          +---------+----------+
>                          |A        |IP_1      |
>                          +---------+----------+
>                          |A        |IP_2      |
>                          +---------+----------+
>                          Figure 2 Instance of FT
>
>7. Binding States Description
>
>   This section describes the binding states of this mechanism.
>
>   START        A DHCP request (or a DHCPv6 Confirm) has been received
>   from host, and it may trigger a new binding.
>
>   LIVE       A DHCP address has been acknowledged by a DHCP server.
>
>   DETECTION    A gratuitous ARP or Duplicate Address Detection NSOL
>   has been sent by the host (or the SAVI device).
>
>   BOUND       The address has passed duplicate detection and
>             it is bound with the anchor.
>
>8. DHCP Scenario
>
>   (This section should be removed and merged with other scenarios in
>   [savi-framework])
>
>   This section specifies the deployment scenarios of this mechanism.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Bi                      Expires May 9, 2010                  [Page 6]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>                                +--------+
>                                | DHCP   |
>                                | Server |
>                                +-------,+
>                                    `.
>                                    `.
>                                    `.
>                               +----'-----+
>                               |  SAVI    |
>                               |  Device  |
>                               +-/------/-+
>                                 |      |
>                            +----\-+   +\-----+
>                            |DHCP  |   |Client|
>                            |Relay |   |      |
>                            +------+   +------+
>                          Figure 3 DHCP Scenario
>
>9. Anchor Attributes
>
>   This section specifies the anchor attributes involved in this
>   mechanism.
>
>9.1. SAVI-Host Attribute
>
>    (This attribute should be described in the [savi-framework])
>
>   If and only if an anchor is exclusively associated with a single host,
>   this anchor can be set to have SAVI-Host attribute.
>
>9.2. SAVI-Poly Attribute
>
>   (This attribute should be described in the [savi-framework])
>
>   If an anchor is associated with a small number of hosts through a
>   converged device, this anchor can be set to have the SAVI-Poly
>   attribute. The SAVI-Poly attribute is mutually exclusive with the
>   SAVI-Host attribute.
>
>   The main difference in process on an anchor with the SAVI-Poly
>   attribute from one with the SAVI-Host attribute is the policy of
>   binding consistency.
>
>9.3. SAVI-DHCP-Trust Attribute
>
>   If and only if an anchor is associated with a trustable DHCP
>   server/relay, it can be set to have this attribute.
>
>
>Bi                      Expires May 9, 2010                  [Page 7]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   If DHCP is used to assign address in the network, there MUST be at
>   least one anchor with this attribute. DHCP Reply message not coming
>   from such ports MUST be dropped.
>
>9.4. SAVI-RA-Trust Attribute
>
>   (This attribute should be described in the [savi-framework])
>
>   If and only if an anchor is associated with a trustable router, it
>   can be set to have this attribute.
>
>   There MAY be no SAVI-RA-Trust anchor on a SAVI device.
>
>   Router Advertisement not received from a SAVI-RA-Trust anchor MUST be
>   discarded.
>
>9.5. SAVI-SAVI Attribute
>
>   (This attribute should be described in the [savi-framework])
>
>   If and only if an anchor is associated with another SAVI device, it
>   can be set to have this attribute.
>
>   This attribute is mutually exclusive with SAVI-Host and SAVI-Poly
>   attribute.
>
>10. Prefix Configuration
>
>   (This section should be included in [SAVI-framework] but not this
>   document.)
>
>   Before setting up a host-level granularity binding table, it is
>   important to configure correct prefixes on the SAVI device. At least
>   two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes.
>   This document suggests set 3 prefix scopes:
>
>  IPv4 Prefix:
>
>         The allowed scope of any kind of IPv4 addresses. It can be set
>         manually.
>
>   IPv6 SLAAC Prefixes:
>
>         The allowed scope of SLAAC and manually configured IPv6
>         addresses. It can be set through snooping RA message from port
>         with SAVI-RA-Trust attribute, or manual configuration.
>
>
>
>Bi                      Expires May 9, 2010                  [Page 8]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>         FE80::/64 MUST be set to a feasible prefix.
>
>   IPv6 DHCPv6 Prefixes:
>
>         The allowed scope of DHCPv6 addresses. It can be set through RA
>         snooping, DHCP-PD protocol, or manual configuration.
>
>   If some of the prefix scope is set to have non prefix, it implies
>   corresponding address assignment method is not allowed in the network.
>
>   There is no need to explicitly present these prefix scopes. But these
>   restrictions MUST be used as premier check in binding set up.
>
>   Refer to security consideration for other discussions.
>
>11. Binding Set Up
>
>   This section specifies the procedure of setting up bindings based on
>   control packet snooping.
>
>11.1. Process of DHCP Snooping
>
>11.1.1. Initialization
>
>   This procedure will not be performed if:
>
>   1. Option 82 is used to keep anchor in DHCP Request and Reply, or
>
>   2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or
>
>   3. The mapping table from MAC to anchor is secure.
>
>   If none of these three requirements are satisfied, this procedure
>   MUST be performed.
>
>11.1.1.1. Trigger Event
>
>   A DHCPv4/v6 Request or a DHCPv6 Confirm is received with an anchor
>   which has the attribute of SAVI-Host or SAVI-Poly.
>
>11.1.1.2. Message Validation
>
>   The SAVI device checks the Request or Confirm as follows:
>
>   1. Whether the limitation on binding entry number of this anchor will
>      be exceeded.
>
>
>
>Bi                      Expires May 9, 2010                  [Page 9]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>11.1.1.3. Following Actions
>
>   Forward the REQUEST message if binding entry limitation will not be
>   exceeded.
>
>   Generate an entry in the Binding State Table (BST) and set the state
>   field to START. The lifetime of this entry is set to be
>   MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in
>   [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet
>   is also recorded in the entry.
>
>   +---------+----------+-------+-----------------------+-------+
>   | Anchor  | Address  | State | Lifetime              |Other  |
>   +---------+----------+-------+-----------------------+-------+
>   | A       |          | Start |MAX_DHCP_RESPONSE_TIME | TID   |
>   +---------+----------+-------+-----------------------+-------+
>              Figure 4 Binding entry in BST on initialization
>
>   The TID is kept for assurance that the response from the DHCP server
>   can be delivered to the request host. This is left as an open issue
>   for future discussion.
>
>11.1.2. From START to LIVE
>
>11.1.2.1. Trigger Event
>
>   A DHCPv4 DHCPACK or DHCPv6 REPLY message is received.
>
>11.1.2.2. Message Validation
>
>   The SAVI device checks the message as follows:
>
>   1. Whether the message is received with an anchor which has the SAVI-
>      DHCP-Trust attribute;
>
>   2. Whether the entry in the BST with corresponding TID is in the
>      START state.
>
>11.1.2.3. Following Actions
>
>   Deliver the message to the destination.
>
>   Set the state of the corresponding entry to be LIVE. The lifetime of
>   the entry is set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY
>   respectively. The lease time is also recorded in the entry.
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 10]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   +---------+----------+-------+------------------------+-------+
>   | Anchor  | Address  | State | Lifetime               |Other  |
>   +---------+----------+-------+------------------------+-------+
>   | A       | Addr     | LIVE  |MAX_ARP_PREPARE_DELAY or| Lease |
>   |         |          |       |MAX_DAD_PREPARE_DELAY   | Time  |
>   +---------+----------+-------+------------------------+-------+
>                Figure 5 Binding entry in BST on assignment
>
>   Or set the state of the corresponding entry to be DETECTION, and send
>   an ARP Request or NSOL for the assigned address.
>
>   +---------+----------+-----------+-----------------+-------+
>   | Anchor  | Address  | State     | Lifetime        |Other  |
>   +---------+----------+-----------+-----------------+-------+
>   | A       | Addr     | DETECTION |MAX_ARP_DELAY or | Lease |
>   |         |          |           |MAX_DAD_DELAY    | Time  |
>   +---------+----------+-----------+-----------------+-------+
>         Figure 6 Binding entry in BST on assignment: another case
>
>   Insert an entry into the Filtering Table if the assigned address is
>   not bound with another anchor.
>
>                          +---------+----------+
>                          |Anchor   |Address   |
>                          +---------+----------+
>                          |A        |Addr      |
>                          +---------+----------+
>                Figure 7 Binding entry in FT on assignment
>
>11.1.3. From LIVE to DETECTION
>
>   (This section should be removed or modified if all the DAD related
>   procedures are to be described in SLAAC document)
>
>11.1.3.1. Trigger Event
>
>   A gratuitous ARP Request or Duplicate Address Detection Neighbor
>   Solicitation is received from the host. Or a timeout event of an
>   entry with state LIVE occurs.
>
>11.1.3.2. Message Validation
>
>   The SAVI device checks the message as follows:
>
>   1. Whether the Target IP address field of the ARP Request or Neighbor
>      Solicitation has been bound with the corresponding anchor in BST
>      or FT.
>
>
>Bi                      Expires May 9, 2010                 [Page 11]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>11.1.3.3. Following Actions
>
>   If timeout event of an entry with state LIVE happens, send an ARP
>   Request or a DAD NSOL, with target address set to the recorded
>   address in the entry.
>
>   Set the state of the entry to be DETECTION. The lifetime of the entry
>   is set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively.
>
>   +---------+----------+-----------+-----------------+-------+
>   | Anchor  | Address  | State      | Lifetime       |Other  |
>   +---------+----------+-----------+-----------------+-------+
>   | A       | Addr     | DETECTION  |MAX_ARP_DELAY or| Lease |
>   |         |          |            |MAX_DAD_DELAY   | Time  |
>   +---------+----------+-----------+-----------------+-------+
>                Figure 8 Binding entry in BST on detection
>
>11.1.4. From DETECTION to BOUND
>
>11.1.4.1. Trigger Event
>
>   A timeout event of an entry with state DETECTION occurs or an ARP
>   Response or NA for an address in BST with state DETECTION is received.
>
>11.1.4.2. Following Actions
>
>   If a timeout event of an entry with state DETECTION occurs, set the
>   state of the entry to be BOUND. The lifetime of the entry is set to
>   be the Lease time acknowledged by DHCP server.
>
>   +---------+----------+-----------+----------------+-------+
>   | Anchor  | Address  | State     | Lifetime       |Other  |
>   +---------+----------+-----------+----------------+-------+
>   | A       | Addr     | BOUND     | Lease time     |       |
>   +---------+----------+-----------+----------------+-------+
>               Figure 9 Binding entry in BST on finalization
>
>   If an ARP Response or NA for an address in BST with state DETECTION
>   is received, remove the corresponding entry in BST and FT.
>
>11.1.5. After BOUND
>
>   Whenever a DHCP Decline is received from the host, delete the entry
>   in BST and FT.
>
>   Whenever a DHCP Release is received from the host, if the state of
>   the entry is BOUND, delete the entry in BST and FT.
>
>
>Bi                      Expires May 9, 2010                 [Page 12]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is
>   received from the server, set lifetime of the entry in BST to be the
>   new lease time.
>
>   If the lifetime of an entry with state BOUND expires, delete the
>   entry in BST and Filter Table.
>
>11.2. State Machine of DHCP Snooping
>
>   State     Packet/Event      Action                 Next State
>
>   -*         REQUEST/CONFIRM   Set up new entry                  START
>
>   START      ACK                Record lease time                  LIVE
>
>   START      Timeout            Remove entry                          -
>
>   LIVE       Gra ARP REQ/DAD NS    -                          DETECTION
>
>   LIVE       DECLINE             Remove entry                         -
>
>   LIVE       Timeout            Send ARP Req/DAD NS         DETECTION
>
>   DETECTION  Timeout             -                                BOUND
>
>   DETECTION  ARP RESPONSE        Remove entry                         -
>
>   DETECTION  DECLINE             Remove entry                         -
>
>   BOUND      RELEASE/DECLINE     Remove entry                         -
>
>   BOUND      Timeout             Remove entry                         -
>
>   BOUND      RENEW/REBOUND       Set new lifetime                 BOUND
>
>   *: optional.
>
>12. Filtering Specification
>
>   This section specifies how to use bindings to filter packets.
>
>12.1. Filter Data Packet
>
>   Data packets with an anchor which has attribute SAVI-Host or SAVI-
>   Poly are filtered. There can be an anchor with neither attribute.
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 13]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   If the source of a packet associated with its anchor is in the FT,
>   this packet will be forwarded; or else the packet MUST be discarded.
>
>12.2. Filter Control Packet
>
>   The source address of DHCPv4 Request/Discovery must be set to all
>   zeros.
>
>   The source address of DHCPv6 Request/Confirm must be an address
>   associated with the corresponding anchor in FT.
>
>   The source address of IPv6 NS and IPv6 gratuitous ARP must pass the
>   check on FT. The source address of DAD NS MUST be unspecified address.
>
>   All DHCP Reply/Ack packets MUST be from an anchor with the SAVI-DHCP-
>   Trust attribute.
>
>   The target address and source address in all the Neighbor
>   Advertisement packets and ARP replies must also pass the checks on FT,
>   if they are associated with anchors which have SAVI-Host or SAVI-Poly
>   attribute.
>
>13. Format and Delivery of Probe Messages
>
>   1. Duplicate detection on behavior of host;
>
>      Message Type: DAD NS, Gratuitous ARP Request
>
>      Format:
>
>                   Link layer source - link layer address of host;
>
>                   Link layer destination - For IPv6, use multicast address
>      specified in [RFC3307]; For IPv4, use broadcast address;
>
>                   IP source - Unspecified address for IPv6; The tentative address
>      for IPv4;
>
>                   IP destination - For IPv6, multicast address specified in
>      section 5.4.2 of [RFC4861]; For IPv4, the tentative address;
>
>      Delivery:
>
>         MUST not deliver to the host which the SAVI device is
>      performing DAD on behavior of.
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 14]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   2. Send reply on behavior of host to hold bound address for inactive
>      node;
>
>      Message Type: NA, ARP Response
>
>      Link layer source - link layer address of host;
>
>      Link layer destination - The source address of the detecting node;
>
>      IP source - The target address in the detection message;
>
>      IP destination -The source address of the detecting node;
>
>   3. Send probe to detect whether an address is still in use (generally
>      in case of port down/up event).
>
>      Message Type: NUD, ARP Request
>
>      Link layer source - link layer address of the SAVI device;
>
>      Link layer destination - The link layer address of the node;
>
>      IP source - The manage IP address of the SAVI device;
>
>      IP destination - The address is suspicious to be inactive.
>
>14. Data packet trigger on SAVI-Poly anchor
>
>   To handle the case of movement from one SAVI-Poly port to another,
>   data packet based binding MUST be performed on SAVI-Poly anchor.
>
>   Whenever a packet with source address not bound locally is received
>   from a SAVI-Poly anchor, the SAVI device MUST send a DHCP CONFIRM to
>   the DHCP server to ensure the address can be used on the link; if the
>   address can be used, the SAVI device MUST send a DAD NS on behavior
>   of the host to check the uniqueness of the address. If the address
>   passes these two checks, it can be bound with the anchor.
>
>   Data packet triggered binging will cause heavy burden and
>   unpredictable danger on the SAVI device. It is not suggested to
>   configure SAVI-Poly anchor and allow mobility between SAVI-Poly
>   anchors. If this function is turned off, the administrator must be
>   aware of the packets from SAVI-Poly anchor may be filtered
>   incorrectly after movement.
>
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 15]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>15. Binding Remove
>
>   If the lifetime of an entry with state BOUND expires, the entry MUST
>   be removed.
>
>   When the SAVI device receives a DAD NS/Gra ARP request target at an
>   address bound and there is no reply from the anchor, if the anchor is
>   a SAVI-Host anchor, hold the binding entry through sending NA/ARP
>   Reply; if the anchor is a SAVI-Poly anchor, remove this binding or
>   hold it.
>
>16. Handle port DOWN event
>
>   Whenever a port with attribute SAVI-Poly or SAVI-Host turns down, the
>   bindings with the anchor MUST be kept for a short time.
>
>   To handle movement, if receiving DAD NS/Gra ARP request target at the
>   address during the period, remove the entry.
>
>   If port turns UP during the period:
>
>        ?Optionally send probes to SAVI-host port for assurance;
>
>        ?MUST send probes to SAVI-Poly port for assurance.
>
>17. About Collision in Detection
>
>   The SAVI device may receive a response in detection. Some related
>   details are specified here.
>
>17.1. Whether to notify the DHCP server
>
>   It is unnecessary for the SAVI device to notify the DHCP server,
>   because the host will send a DECLINE message to it once it finds the
>   advertised address is conflict.
>
>17.2. The result of detection without host aware
>
>   In case the SAVI device send detection packet instead of the host,
>   the host will not be aware of the detection result. If the detection
>   succeeds, there is no problem. However, if the detection fails, the
>   packets from the host with the assigned address will be filtered out.
>   This result can be regarded as a reasonable punishment for not
>   performing duplicate detection and using a collision address.
>
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 16]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>18. Filtering during detection
>
>   In this mechanism, whenever the DHCP server replies an address, this
>   address will be allowed immediately even before duplicate detection
>   is completed. This design is in consideration of a host may start to
>   send packets straightway without detection. Also this design is to be
>   compatible with optimistic DAD [RFC4429].
>
>   However, this feature may allow an attacker to send quantities of
>   packets with source addresses already assigned to other nodes. A
>   practical solution for this vulnerability is configuring the address
>   pool and allocation algorithm of the DHCP server carefully.
>
>19. Binding Number Limitation
>
>   It is suggested to configure some mechanism in order to prevent a
>   single node from exhausting the binding table entries on the SAVI
>   device. Either of the following mechanism is sufficient to prevent
>   such attack.
>
>   1. Set the upper bound of binding number for each anchor with SAVI-
>      Host or SAVI-Poly attribute.
>
>   2. Reserve a number of binding entries for each anchor with SAVI-Host
>      or SAVI-Poly attribute and all anchors share a pool of the other
>      binding entries.
>
>   3. Limit DHCP Request rate per anchor, using the bound entry number
>      of each anchor as reverse indicator.
>
>20. MLD Consideration
>
>   The SAVI device MUST join the tentative address multicast group
>   whenever perform duplicate detection on behavior of host.
>
>21. Constants
>
>   MAX_DHCP_RESPONSE_TIME     120s
>
>   MAX_ARP_PREPARE_DELAY      Default 1s but configurable
>
>   MAX_ARP_DELAY              Default 1s but configurable
>
>   MAX_DAD_PREPARE_DELAY      Default 1s but configurable
>
>   MAX_DAD_DELAY              Default 1s but configurable
>
>
>
>Bi                      Expires May 9, 2010                 [Page 17]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>22. Summary of to-be-removed sections and open issues
>
>   To-be-removed sections:
>
>   1. Section 6: Conceptual data structures
>
>   2. Section 8: DHCP scenario
>
>   3. Part of Section 9: Anchor attributes
>
>   4. Section 10: Prefix configuration
>
>   Open issues (discussed but not finished):
>
>   1. Whether to keep state START
>
>      Should the procedure be initialized based on client request or
>      server response?
>
>      From Eric Levy-Abegnoli and Christian Vogt.
>
>   2. Whether to keep state DETECTION
>
>      Should DHCP interact with NDP to detect collision or should all
>      the collision detection be left to NDP and the DHCP solution just
>      snoop DHCP only?
>
>      From Eric Levy-Abegnoli.
>
>23. Security Considerations
>
>   For prefix level granularity filtering is the basis of host level
>   granularity filtering, to learn and configure correct prefix is of
>   great importance to this mechanism. Thus, it's important to keep RA
>   and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a
>   mechanism to improve the security of RA message.
>
>24. IANA Considerations
>
>   There is no IANA consideration currently.
>
>25. References
>
>25.1. Normative References
>
>   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
>             Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>
>Bi                      Expires May 9, 2010                 [Page 18]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>   [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
>             Autoconfiguration", RFC4862, September, 2007.
>
>   [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
>             July 2008.
>
>
>
>25.2. Informative References
>
>26. Acknowledgments
>
>Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik
>Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David
>Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg
>Daley, Joel M. Halpern and Tao Lin for their valuable contributions.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 19]
>
>Internet-Draft                savi-dhcp                  November 2009
>
>
>Authors' Addresses
>
>   Jun Bi
>   CERNET
>   Network Research Center, Tsinghua University
>   Beijing 100084
>   China
>   Email: [email-masked]
>
>   Jianping Wu
>   CERNET
>   Computer Science, Tsinghua University
>   Beijing 100084
>   China
>   Email: [email-masked]
>
>   Guang Yao
>   CERNET
>   Network Research Center, Tsinghua University
>   Beijing 100084
>   China
>   Email: [email-masked]
>
>
>   Fred Baker
>   Cisco Systems
>   Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Bi                      Expires May 9, 2010                 [Page 20]
>
>  
>

---

From: "rengang" <[email-masked]>
Date: Wed, 11 Nov 2009 02:00:48 +0800

Yes, I think the working group should adopt "draft-bi-savi-dhcp-00" as a WG
draft for the SAVI protocol specification for DHCP-assigned IP addresses.

Ren Gang

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Christian
Vogt
发送时间: 2009年11月9日 18:45
收件人: SAVI Mailing List
抄送: Guang Yao
主题: [savi] Consensus call on adopting draft-bi-savi-dhcp-00

Folks -

- Christian

---

From: "xuke" <[email-masked]>
Date: Fri, 20 Nov 2009 18:10:22 +0800

Yes,
xuke