Subject: I-D Action:draft-ietf-6man-node-req-bis-04.txt

From: [email-masked]
Date: Mon, 8 Mar 2010 13:30:02 -0800 (PST)

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           : IPv6 Node Requirements RFC 4294-bis
	Author(s)       : E. Jankiewicz, et al.
	Filename        : draft-ietf-6man-node-req-bis-04.txt
	Pages           : 24
	Date            : 2010-03-08

This document defines requirements for IPv6 nodes.  It is expected
that IPv6 will be deployed in a wide range of devices and situations.
Specifying the requirements for IPv6 nodes allows IPv6 to function
well and interoperate in a large number of situations and
deployments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-04.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 10 Mar 2010 18:58:32 +0900

I noticed the VRRP for IPv4 and IPv6 RFC
was just published. I have seen implementations of
VRRP or HSRP (IPv6) and some only allow link local
vips to be configured. From an operational viewpoint
it would be preferable to have a global address vip,
but there's nothing wrong with a link local vip.

However, I have come across quite a few implementations (usually
middle boxes) where I try to configure a static route with
the next hop as a link local address but
link local next hops are not allowed.
These nodes can't communicate with a VRRP link-local vip.

Is this appropriate material to be covered in the
node requirements document?

Thanks and regards,
Seiichi

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ole Troan <[email-masked]>
Date: Fri, 12 Mar 2010 13:10:21 +0100

a comment on section 5.8.5 on stateful address autoconfiguration.

    "5.8.5.  Stateful Address Autoconfiguration

   Stateful Address Autoconfiguration MAY be supported.  DHCPv6
   [RFC3315] is the standard stateful address configuration protocol;
   see Section 6.2 for DHCPv6 support.

   Nodes which do not support Stateful Address Autoconfiguration may be
   unable to obtain any IPv6 addresses, aside from link-local addresses,
   when it receives a router advertisement with the 'M' flag (Managed
   address configuration) set and that contains no prefixes advertised
   for Stateless Address Autoconfiguration (see Section 4.5.2).
   Additionally, such nodes will be unable to obtain other configuration
   information, such as the addresses of DNS servers when it is
   connected to a link over which the node receives a router
   advertisement in which the 'O' flag (Other stateful configuration) is
   set."

I'd like to see support for DHCP address assignment be at least a SHOULD.
I want to see DHCP for other configuration information as a MUST.

doesn't 6.2.1 / 6.2.2 and 5.8.5 overlap?
nit on section 6.2.1 \'M'- flag, header says 5.2.1.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Mar 2010 08:40:54 +1300

Ole,

> I want to see DHCP for other configuration information as a MUST.

The original intention of SLAAC was for extremely simple (at the
time, we called them "dentist's office") deployments, where in fact
the analogy was with Appletalk's admirable plug and play. RFC5006
makes that viable (just). I don't think that node-requirements should
remove that option.

I agree that for more complex situations, DHCP may be a practical
requirement. We can describe that with a qualified SHOULD.

    Brian