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.