Subject: I-D Action: draft-ietf-6man-dad-proxy-07.txt

From: [email-masked]
Date: Tue, 09 Apr 2013 10:48:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Duplicate Address Detection Proxy
	Author(s)       : Fabio Costa
                          Jean-Michel Combes
                          Xavier Pougnard
                          Hongyu Li
	Filename        : draft-ietf-6man-dad-proxy-07.txt
	Pages           : 15
	Date            : 2013-04-09

Abstract:
   The document describes a proxy based mechanism allowing the use of
   Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
   multipoint architecture with "split-horizon" forwarding scheme,
   primarily deployed for Digital Subscriber Line (DSL) and Fiber access
   architectures.  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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-dad-proxy-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Karl Auer <[email-masked]>
Date: Wed, 10 Apr 2013 08:11:31 +1000

On Tue, 2013-04-09 at 10:48 -0700, [email-masked] wrote:
> Abstract:
>    The document describes a proxy based mechanism [...]
>    Based on the DAD signalling, the first hop router

Coming late to this but - DAD NS frames are sent to solicited node
multicast addresses, so how is the first hop router seeing them?
IPv6-aware (MLD snooping) switches won't forward the DAD NS frames
except to members of the SNM group...?

What am I missing?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: Brian Haberman <[email-masked]>
Date: Fri, 12 Apr 2013 09:52:02 -0400

Hi Karl,

> except to members of the SNM group...?

The proxy would have to maintain a list of nodes being proxied.  In that 
case, the proxy can join the solicited-node multicast address for those 
nodes.

Regards,
Brian

---

From: Karl Auer <[email-masked]>
Date: Sat, 13 Apr 2013 09:01:04 +1000

> case, the proxy can join the solicited-node multicast address for those 

I'm still missing something then. How does the BNG build the list? I
just re-read the draft and can see no mechanisms mentioned except
snooping on DAD (which won't work except unless the proxy is already
listening on the relevant SNMA) and unsolicited NAs. Nor is there any
statement in the draft (for example in the "data structures" section,
4.1) that the proxy should join any solicited node multicast groups.
Solicited node multicast addresses are mentioned in only two places: In
section 3.1, which describes DAD in a misleadingly rather vague way
under the circumstances (DAD packets go to "other nodes on the same
link"), and in section 4.2.2 only in a negative sense (a case where a
packet "other than a solicited Neighbor Advertisement" is received).

Apologies if I'm missing something really obvious. Humbly asking for
enlightenment :-)

Regards, K.

---

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 15 Apr 2013 13:30:53 +0200

Hi Karl,

in a VLAN N:1 architecture with "split-horizon" forwarding scheme, all IP
flows are forwarded through the BNG. So, the BNG is able to see them.

Best regards,

JMC.

2013/4/10 Karl Auer <[email-masked]>

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>