Subject: [renum] Forward: New Version Notification for draft-liu-ipv6-renum-conflicts-00

From: Jiangsheng <[email-masked]>
Date: Mon, 07 Mar 2011 16:01:56 +0000

Title: New Version Notification for draft-liu-ipv6-renum-conflicts-00

A new version of I-D, draft-liu-ipv6-renum-conflicts-00.txt has been successfully submitted by Sheng Jiang and posted to the IETF repository.

Filename:        draft-liu-ipv6-renum-conflicts
Revision:        00
Title:           SLAAC/DHCPv6 conflicts diagnostic during site renumbering
Creation_date:   2011-03-07
WG ID:           Independent Submission
Number_of_pages: 8

Abstract:
While an IPv6 site is being renumbered, both DHCPv6 and ND may be
used to reconfigure the host addresses. This may cause potential
address configuration conflicts during renumbering procedure. The
issue mainly include two situations: a) Address configuration method
conflict, which means a host receives a new prefix comes from another
address configuration protocol. b) Address prefix conflict, a host
receives both DHCPv6 and ND address configuration messages which
assign different address prefixes. This documents analyzes the
conflict issues and proposes a conflict report mechanism for hosts to
report the conflicts to DHCPv6 servers.

The IETF Secretariat.

---

From: Teco Boot <[email-masked]>
Date: Mon, 7 Mar 2011 21:54:11 +0100

Hi Sheng,

I don't understand why you say a node cannot use DHCP and 
SLAAC in parallel. IMHO an IPv6 node may configure whatever
number of addresses on its interfaces, with whatever mechanism.

Thanks, Teco

Op 7 mrt 2011, om 17:01 heeft Jiangsheng het volgende geschreven:

> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: Jiangsheng <[email-masked]>
Date: Tue, 08 Mar 2011 13:37:57 +0000

Hi, Teco,

For sure, a node can use both DHCP and SLAAC in parallel. 

However, our point here is this is a potential problem creator. If DHCP and SLAAC gave different prefixes (for whatever the reason including human configuration errors), the node itself has no enough intelligence to choose between them. We need either a mechanism to report such errors or a full management system to make sure such errors cannot happen. Our document is only targetting these kinds of failure scenarios, not generic DHCP and SLAAC co-exisiting. 

Regards,

Sheng
________________________________________
Title: Re: [renum] Forward: New Version Notification for draft-liu-ipv6-renum-conflicts-00

Hi Sheng,

Thanks, Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 8 Mar 2011 19:36:32 +0100

Sheng,

>     If DHCP and SLAAC gave different prefixes (for whatever the reason including human configuration errors), the node itself has no enough intelligence to choose between them. We need either a mechanism to report such errors or a full management system to make sure such errors cannot happen.
Why not just pick one and go for it? Or better, add a function in ND & routing, so that nodes are better informed what address fits bests? Then, there is no need for reporting errors, or a full management system which isn't in place in many cases.

Teco

---

From: Jiangsheng <[email-masked]>
Date: Tue, 08 Mar 2011 20:50:37 +0000

Sheng,

> Why not just pick one and go for it? Or better, add a function in ND & routing, so that nodes are better informed what address fits bests? Then, there is no need for reporting errors, or a full man…

Sheng: firstly, we are not targetting the prefix choosing among several available and correct prefixes. The choosing function is also helpful, but out of scope for our document. We are talking about there are errors.

>From host perspective, it is almost impossible to tell an error prefix from several available prefixes. So, reporting the error is the only choice. From network perspective, such host-feedback diagnosis function is helpful since the network cannot prevent such errors by current available protocol definitions.

Sheng

---

From: Tim Chown <[email-masked]>
Date: Sat, 19 Mar 2011 23:41:57 +0000

> From host perspective, it is almost impossible to tell an error prefix from several available prefixes. So, reporting the error is the only choice. From network perspective, such host-feedback diag…

That's also true for rogue RAs.    At the moment the methods to mitigate such problems are usually either ACLs on switches, or tools like RAmond that are configured to counter the rogue advertisements.   RAmond(*) can't detect issues with unicast RAs though (or rogue DHCPv6 servers) because as it stands it's only a passive monitoring tool.   Extending RAmond to include active checks may give you some of what you want without needing to alter hosts.

As an aside, I've offered to present a 5-minute summary of our findings from a year's worth of RAmond logging in v6ops in Prague.

Tim

(*) http://ramond.sourceforge.net