Duplicate Address Detection Proxy
RFC 6957

[Ballot comment]

JMC proposed adding: "If so, the SAVI device is the BNG and the Binding Anchor for a CPE is its MAC address, which is assumed to be unique in this document (cf. Section 1)." which seems good to me.

- The last sentence in the abstract confused me, what's
"this last one" mean?

- I agree with Martin and Sean's DISCUSSes.

[Ballot discuss]
Sorry about the ping-pong! Brian and i have been discussing this
further and have talked ourselves back into believing that I have a
valid concern. So I have moved it back from my Comment and reworded it
(with a little help from Brian).

There are two scenarios that give rise to concern:

1. Node A with address a sends NS. The message is lost in the network.
  Because the message is not normally acknowledged, when Node B sends
  NS with the same address, the duplication is not noticed.

  Note that an obvious variation of this scenario is when the NS from
  Node B is lost.

2. Node A with address a sends NS. The message reaches the BNG and is
  added to the cache. At a later time, the cache becomes full and this
  entry is discarded according to some local policy. Now Node B sends
  NS with the same address. The duplicate is added to the cache, but
  the duplication is not noticed.

  Note that a variation on the second scenario occurs when the policy
  of a full cache is to ignore new NSes. This variant gives rise to
  scenario 1 with the message loss being in the BNG.

So, it is not reasonable for this document to have to fix DAD. The
problem of lost messages exists in DAD (although at a slightly less
probable level because normally there is a chance for Node A to receive
Node B's NS even if Node A's NS was lost). I think that the first
scenario can be handled in this document simply by noting that the
problem exists and is made slightly more of an exposure when a proxy is
used because the loss of either of the NSes will lead to duplication
being missed.

I think that the second scenario is only a problem if the Binding Table
is not large enough. So it is clear that "the Binding Table MUST be
large enough for the deployment in which it is used." You certainly need
to say this, and you should add some guidance. You also need to add that
implementations MUST either state the fixed size of Binding Table that
they support or make the size configurable. In the latter case,
implementations MUST state the largest Binding Table size that they
support. Additionally, implementations SHOULD allow an operator to
enquire the current occupancy level of the Binding Table to determine if
it is about to become full.

If you do all that, you only need to note that implementations
encountering a full Binding Table will likely handle it in a way similar
to NS message loss.

And all of that just leaves me with one last question which is: since NS
is not refreshed in DAD, is there a risk that the cache will grow
forever with undisciplined nodes disappearing or renumbering without
bothering to tell the BNG? That would be bad.

---

Shouldn't you describe some manageability considerations? What events
should be logged? What access to the stored informaiton should be
provided? (For example, should the operator be able to read the Binding
Table?)

[Ballot discuss]
Updated Discuss after Telechat conversation with Brian. I have moved
my first point into a Comment and added some clarification.

---

Shouldn't you describe some manageability considerations? What events
should be logged? What access to the stored informaiton should be
provided? (For example, should the operator be able to read the Binding
Table?)

[Ballot comment]
In my Discuss I originally wrote:

> I don't see any discussion of the size of the Binding Table. In
> fact, it seems to be assumed to be "large enough". History shows
> that we are not good at guessing the value of "large enough" and
> certainly the application of this mechanism to VPNs makes this a
> little worrying. That probably means that the document needs to
> describe what happens when the Binding Table is full. Might be as
> simple as handling the failure case in 4.2.1.

First, don't be distracted by the VPN thing. I am just asking about
what happens when a BNG receives a Neighbor Solicitation message and
is unable to store the tentative address as mandated in Section 4.2.1.

Brian says that the protocol is unreliable, so it is as simple as making
a local decision to drop the message or flush an entry from the cache.
That sounds fine to me, and I started to look for text in the I-D that
describes "lost message", "cache full", "cache cycling", and "cache
timeout".

I am not convinced that this is an issue. But I am slightly worried
about the impact of a node that has been happily alive and running
suddenly being dropped from the cache and "replaced" by another node
with the same address.

[Ballot discuss]
I don't see any discussion of the size of the Binding Table. In fact, it
seems to be assumed to be "large enough". History shows that we are not
good at guessing the value of "large enough" and certainly the
application of this mechanism to VPNs makes this a little worrying. That
probably means that the document needs to describe what happens when the
Binding Table is full. Might be as simple as handling the failure case
in 4.2.1.

---

Shouldn't you describe some manageability considerations? What events
should be logged? What access to the stored informaiton should be
provided? (For example, should theoperator be able to read the Binding
Table?)

[Ballot discuss]

Does the deployment model for this actually fit the SAVI
charter which is limited to systems on the same IP link? Its
not clear to me that it does, and if it doesn't then I'm not
sure how SAVI "MAY be used" to protect against address
spoofing. (It could be that this does fit with SAVI, I'm just
not sure.)

[Ballot comment]
1)
I have no general concern about the publication of the draft, but I doubt that it is for the Internet in general.

It is more adding support for a very specific set of deployments, e.g., DSL access networks.
This is somehow stated in the abstract "point-to-multipoint architecture with "split-horizon" forwarding scheme." but it is hard to understand and the proposed solution probably does not work in other settings that use the same description or claim similar ground.

Can we add a more specific wording right upfront that this is primarly for "Digital Subscriber Line (DSL) and Fiber access architectures" as noted in Section 2?

This would also be inline with the rest of the document which uses very specific terminology out of broadband access networks, e.g., BNG. The Internet itself does not has BNGs, but routers or first hop routers (AKA BNG in this context)

Also in this context:
Section 3.2., paragraph 3:

>    As the BNG must not forward link-local scoped messages sent from a
>    CPE to other CPEs, ND Proxy cannot be implemented in the BNG.

  This seems to be the restriction of a very specific deployment
  scenario, but is not a limitation per se. Other people could allow this in their architecture.

2)
Section 4.1., paragraph 1:

>    A BNG needs to store in a Binding Table information related to the
>    IPv6 addresses generated by any CPE.  This Binding Table MAY be
>    distinct from the Neighbor Cache.  This must be done per point to

  This 'MAY' does not look correct here, but a 'can' would just do the job,
  as this is implementation specific, isn't it?

3)
Appendix A., paragraph 1:

>    This appendix contains a summary (cf. Table 1) of the actions done by
>    the BNG when it receives a DAD based NS (DAD-NS) message.  The
>    tentative address in this message is IPv6-CPE1 and the associated
>    Link-layer address is Link-layer-CPE2.  The actions are precisely
>    specified in Section 4.2.

  Is this appendix normative or not? What takes precedence: the text or the table?

[Ballot discuss]
s6.1, para 1: When won't using SEND without a proxy break the security?  I think what you're trying to say is that using plain old SEND won't work you've got to use SEND with the proxy - right?

[Ballot comment]
1) Is the word "proxy" missing from the following in the abstract:

The document describes a mechanism allowing the use of Duplicate
Address Detection (DAD) by IPv6 nodes in a point-to-multipoint
architecture with "split-horizon" forwarding scheme.

s1 use "proxy" after DAD and then s1 para 2 says:

  This document explains also why DAD mechanism [RFC4862] cannot be
  used in a point-to-multipoint architecture with "split-horizon"
  forwarding scheme (IPv6 over PPP [RFC5072] is not affected).

And could we make it clear that a proxy is needed:

  This document explains also why DAD mechanism [RFC4862] without a proxy
  cannot be
  used in a point-to-multipoint architecture with "split-horizon"
  forwarding scheme (IPv6 over PPP [RFC5072] is not affected).

2) s4.2: Some minor wording tweaks because I don't know what the MUST pertains to:

OLD:

  perform actions depending on the information in the Binding Table.

NEW:

  perform actions specified in the following sections based on
  the information in the Binding Table.

3) s4.2.1/s4.2.2: What happens if the BNG does reply/forward?

4) s4.1/s4.2.2: Is the neighborhood cache in s4.2.2 the same thing as the binding table in s4.1?

5) s4.2.3.2: L2 header: Which link-layer address is returned to CPE2?  Is it it's own or the one from CPE1?

6) s6.1: Agree with Barry's SHOULD vs MUST discuss.

7) s6.2: r/To ensure a protection/To ensure protection

8) s6.2: not sure you really need the MAY.  Maybe r/MAY/can

IANA has reviewed draft-ietf-6man-dad-proxy-05, which is currently in
Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

[Ballot discuss]
Section 6.1
  To keep the same level of security, Secure Proxy ND Support for SEND
  [RFC6496] SHOULD be used and implemented on the BNG and the CPEs.

SHOULD, and not MUST?  How is it possible to "keep the same level of security" with SEND if you *don't* use Secure Proxy ND Support?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Duplicate Address Detection Proxy) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Duplicate Address Detection Proxy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The document describes a mechanism allowing the use of Duplicate
  Address Detection (DAD) by IPv6 nodes in a point-to-multipoint
  architecture with "split-horizon" forwarding scheme.  Based on the
  DAD signalling, the first hop router stores in a Binding Table all
  known IPv6 addresses used on a point-to-multipoint domain (e.g.
  VLAN).  When a node performs DAD for an address already used by
  another node, the first hop router replies instead of this last one.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard.

The header indicates Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document describes a mechanism allowing the use of Duplicate
Address Detection (DAD) by IPv6 nodes in a point-to-multipoint
architecture with "split-horizon" forwarding scheme. Based on the
DAD signalling, the first hop router stores in a Binding Table all
known IPv6 addresses used on a point-to-multipoint domain (e.g.
VLAN). When a node performs DAD for an address already used by
another node, the first hop router replies instead of this last one.

Working Group Summary

The working group has reviewed and discussed this draft, feel it solves a relevant problem,
and supports it becoming a standard.

Document Quality

This document has been reviewed by many people and the chairs believe there is
agreement in the w.g. to move it forward.

Personnel

Bob Hinden is the Document Shepherd.
Brian Haberman is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Read the document and checked for NITs. It is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The document authors:

Fabio Costa
Jean-Michel Combes
Xavier Pougnard
Hongyu Li

have said they complied with the IPR rules as defined in BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

I am not aware of any IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is a strong consensus to move this forward. The current draft resolves a few
issues raised on the mailing during the w.g. last call. The working groups
thinks it solves an relevant problem.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits. The previous version of the draft had a few issues with some references.
These are fixed in the current draft.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA actions defined in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A