Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix

[<[e-mail]>]

Dear David,

Thank you for these comments.

I’m OK with almost all your edits.

A new revision with these changes will be available very soon.

Thank you.

Cheers,
Med

De : v6ops [mailto:[e-mail]] De la part de David Farmer
Envoyé : vendredi 13 février 2015 09:46
À : [e-mail]
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix


On Feb 11, 2015, at 04:47, [e-mail]<mailto:[e-mail]> wrote:
A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

I support the draft.  However, I have some suggested improvements for the current text.

1.  I'm worried as phrased, section 1, paragraph 3 could be misinterpreted as implying a /64 is a valid end-site prefix.


    A detailed analysis of the 64-bit boundary in IPv6 addressing

    together with the implication for end-site prefix assignment are

    documented in [RFC7421], but no recommendation is included

    in that document.

Maybe just eliminate "together with the implication for end-site prefix assignment", I'm not sure it's necessary or adds much to this discussion to talk about end-site prefix assignments anyway.  However, then the only thing the paragraph says beyond what is in the first paragraph is "but no recommendation is included in that document."  So, how about just deleting this paragraph altogether and adding a version of that idea to the end of the first paragraph, maybe something like this;


    However, such a recommendation was out of scope for that document.


2.  I'd like to see the evolution of the IPv6 Addressing Architecture discussed and used as part of the argument too.  How about the following added as the second paragraph of section 1;


    As discussed in [RFC7421], "the notion of a /64 boundary in the

    address was introduced after the initial design of IPv6, following a

    period when it was expected to be at /80." This evolution of the IPv6

    Addressing Architecture, resulting in [RFC4921], and followed with the

    addition of /127 prefixes for point-to-point links in [RFC6164], clearly

    demonstrates the intent for future IPv6 protocol developments to have

    the flexibility to change this part of the architecture when necessary

    and justified.


3.  I think the first paragraph of section 2 would be clearer if it said;


    IPv6 implementations MUST...


4.  The last paragraph of section 2 makes me think of the scene from Star Wars where Obi-Wan uses the Jedi mind trick on the storm troopers saying, "these aren't the droids you're looking for."


   This recommendation does not conflict with the 64-bit boundary for

   some IPv6 stateless address autoconfiguration (SLAAC, [RFC4864])

   based schemes such as [RFC2464].


Why doesn't it conflict?  Just because we said so?  How about something like this instead;


   This recommendation might seem to conflict with with the 64-bit

   boundary for some IPv6 stateless address autoconfiguration (SLAAC,

   [RFC4864]) based schemes such as [RFC2464].  However, [RFC7421]

   clarifies this is only a parameter in the SLAAC process and using

   DHCPv6 [RFC3315] or manual configuration other longer prefix lengths

   are in operational use.


But does this paragraph even belong in this section?  Maybe move it up into section 1, as well as providing reasons why it does conflict.  How about making this the second paragraph and #2 above the third paragraph of section 1.


5.  Maybe additional informative references to RFC4942 and draft-ietf-opsec-v6 would in order for the security considerations section.  Only referencing RFC4291's security considerations, which says the following, seems really kind of wimpy by today's standards.


    IPv6 addressing documents do not have any direct impact on Internet

    infrastructure security. Authentication of IPv6 packets is defined

    in [AUTH].


(AUTH = RFC 2402)


How about;


    This document does not introduce security issues in addition to what

    is discussed in [RFC4291<https://tools.ietf.org/html/rfc4291>].  Overall IPv6 security issues are more

    completely discussed in [RFC4942] and [draft-ietf-opsec-v6].


Thanks

--
===============================================
David Farmer                          Email: [e-mail]<mailto:[e-mail]>
Office of Information Technology
University of Minnesota
2218 University Ave SE         Phone: [phone]
Minneapolis, MN 55414-3029   Cell: [phone]
===============================================