RE: Node requirements: draft-ietf-6man-node-req-bis-03.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Node requirements: draft-ietf-6man-node-req-bis-03.txt
Thomas,
> raises an intersting point. This document (and RFC 4294) mandate
> (MUST) that hosts implement stateless autoconfiguration. This
> despite that this document is only informational, and no where in
> standards track RFCs is stateless autoconf mandated. This takes us
How about RFC 2462? Standards Track - IPv6 Stateless Address Autoconfiguration.
Regards,
Greg Rabil
-----Original Message-----
From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of Thomas Narten
Sent: Monday, July 20, 2009 4:26 PM
To: ipv6 at ietf.org
Subject: Node requirements: draft-ietf-6man-node-req-bis-03.txt
Hi.
I've posted a revised version of the node requirments ID. This
document had stalled for a while and I volunteered to help move it
along. Wish me/us luck!
The new -03 version has only fairly minor changes relative to
-02. Specifically, they were (IMO) editorial cleanups that were no
brainers. A summary of the changes appears below.
Over the next few days, I will post some additional messages with
specific issues that still need to be resolved. The document will also
be discussed in Stockholm.
They include:
- proper status of this document (info vs. BCP) and whether this
document can update any existing RFC
- Security recommendation. It clearly needs tweaking/updating, but
the fundamental one surrounds the current MUST for IPSec/ESP, MAY
for AH, and SHOULD for some (unspecified) key management.
- DHCP and stateless autoconf. This document is probably not the
right place to discuss the M&O bits, but IMO this document should
say more about DHCP vs. stateless and the issues surrounding when
to implement one or the other. Not to mandate them. Actually, that
raises an intersting point. This document (and RFC 4294) mandate
(MUST) that hosts implement stateless autoconfiguration. This
despite that this document is only informational, and no where in
standards track RFCs is stateless autoconf mandated. This takes us
back to the question of what the scope of this document should be.
If anyone has any other issues they think the document should address,
please speak up.
Thomas
John Loughney says:
> >section 5.1, last paragraph. Shouldn't the doc reference RFC
> >5095 and deprecation of RH0? suggest:
> >
> > An IPv6 node MUST be able to process these headers. An exception is=20
> >Routing Header type 0 (RH0) which is deprecated by [RFC 5095] due to=20
> >security concerns, and which MUST be treated as an unrecognized routing=20
> >type.
>
> Issue 7. I think this would be good to add.
tn: done (and added reference)
> >5.2 - should RFC 5175 - extensions to RA flags - be included?
>
> Issue 8: This would be good to add as well.
tn: done.
> >5.3.1 - would it be redundant to mention the default MTU defined in=20
> >2460, e.g. "The rules in RFC 2460 MUST be followed for default minimum=20
> >MTU size of 1280, packet fragmentation and reassembly."
>
> Issue 9: This seems good to add.
tn: done. see replacement text
> >6.1 - A6 records: is NOT RECOMMENDED strong enough? =20
> >"conventional wisdom" is that A6 has been deprecated, while
> >3363 makes it experimental. Perhaps the node requirements should say=20
> >SHOULD NOT implement A6.
>
> I didn't give this an issue, as I think this is according to 2119 language.
tn: no change. "NOT RECOMMENDED" is equivalent to "SHOULD NOT".
> >7.1.1 - typo - update ref in title to 4213
>
> Issue 10: I think this should be fixed.
tn: Done, but it causes the line to wrap.
> >8. - update ref to RFC 3776 to add RFC 4877 as well. (updates 3776 for
> >4301 architecture)
>
> Issue 11: Yup, this should be fixed.
tn: done.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.