Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 17/02/2017 à 07:32, Lorenzo Colitti a écrit :
That's a valid opinion but it does not reflect the current state of the
IPv6 standards.

Again, let's bear in mind that this discussion is not about changing the
standard, but about reclassifying the existing standards.

I disagree.

The discussion is about advancing a certain standard.

The advancement direction in which limits are reinforced (64bit seems now 'required') is not the right direction.

I prefer the old "IPv6 architecture".

Alex

We can discuss
changing this part of the standard to our heart's content, but *in 6man,
on another document*, not here.

I would be rather surprised if such a discussion ever reached consensus,
but I certainly wouldn't want to dissuade anyone from trying.

On Fri, Feb 17, 2017 at 7:38 AM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx <mailto:albert.e.manfredi@xxxxxxxxxx>> wrote:

    RFC 7421 is informational. And many considerations are not so
    critical anymore, on a specific stateful format.____

    __ __

    I don’t think we need to reinforce the notion that IPv6 must have
    64-bit prefixes, since that is not true now, and should not even be
    made to apply to the currently unused address space. So, I’m opposed
    to text that implies any such restriction, with the exception of (a)
    currently used unicast  address space, (b) SLAAC, (c) ULA, possibly
    other exceptions.____

    __ __

    In other words, *exceptions belong to requiring the 64-bit IID*. Any
    RFC that implies otherwise, IMO, ought to be subject to a –bis
    version.____

    __ __

    Bert____

    __ __

    __ __

    *From:*ipv6 [mailto:ipv6-bounces@xxxxxxxx
    <mailto:ipv6-bounces@xxxxxxxx>] *On Behalf Of *james woodyatt
    *Sent:* Thursday, February 16, 2017 17:21
    *To:* IETF-Discussion Discussion <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>
    *Cc:* 6man WG <ipv6@xxxxxxxx <mailto:ipv6@xxxxxxxx>>;
    draft-ietf-6man-rfc4291bis@xxxxxxxx
    <mailto:draft-ietf-6man-rfc4291bis@xxxxxxxx>; 6man-chairs@xxxxxxxx
    <mailto:6man-chairs@xxxxxxxx>
    *Subject:* Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP
    Version 6 Addressing Architecture) to Internet Standard____

    __ __

    On Feb 16, 2017, at 13:25, otroan@xxxxxxxxxxxxx
    <mailto:otroan@xxxxxxxxxxxxx> wrote:____

        On Feb 13, 2017, at 14:32, David Farmer <farmer@xxxxxxx
        <mailto:farmer@xxxxxxx>> wrote:____

            __ __

            I have concerns with the following text;

               IPv6 unicast routing is based on prefixes of any valid
            length up to
               128 [BCP198].  For example, [RFC6164] standardises 127
            bit prefixes
               on inter-router point-to-point links. However, the
            Interface ID of
               all unicast addresses, except those that start with the
            binary value
               000, is required to be 64 bits long.  The rationale for
            the 64 bit
               boundary in IPv6 addresses can be found in [RFC7421]____

            __ __

            The third sentence seems to limit exceptions to 64 bit IIDs
            to exclusively addresses that start with binary vale of
            000.  There are at least two other exceptions from standards
            track RFCs, that should be more clear accounted for in this
            text. […]____

        __ __

        […]____

        The challenge is to find text that enforces the 64-bit boundary
        policy (ignoring the technical arguments for a moment), and at
        the same time ensures implementors do the right thing and make
        their code handle any prefix length. Of course these are
        interdependent and doing the latter makes it harder to enforce
        the first.____

    __ __

    I propose the following:____

    __ __

                IPv6 unicast routing is based on prefixes of any valid
                length up to 128 bits [BCP198]. However, as explained in
                [RFC7421], the Interface ID of unicast addresses is
                generally required to be 64 bits in length, with
                exceptions only provided in special cases where
                expressly recognized in IETF standards track documents.____

    __ __

    Trying to help out here.____

    __ __

    __ __

    --james woodyatt <jhw@xxxxxxxxxx <mailto:jhw@xxxxxxxxxx>>____

    __ __

    __ __

    __ __


    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@xxxxxxxx <mailto:ipv6@xxxxxxxx>
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/ipv6>
    --------------------------------------------------------------------






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]