Skip to main content

Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-07

Yes

(Brian Haberman)
(Ron Bonica)

No Objection

(Benoît Claise)
(Gonzalo Camarillo)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 05 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -05) Unknown

                            
Ron Bonica Former IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2013-04-11) Unknown
Good job fixing my Discuss. Thanks for the work.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-02-25 for -06) Unknown
Version -06 has resolved my issue in Section 6.1; thanks.
Benoît Claise Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2012-10-09 for -05) Unknown
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?
Pete Resnick Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-10-04 for -06) Unknown
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
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-01-25 for -05) Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -05) Unknown