Subject: Re: <draft-hinden-6man-rfc2464bis-01>

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Jul 2017 17:27:41 +0200

Hi,

There is s typo in there:

> 8.  Differences from RFC 4291                            ^^^^
> 
>    This document has the following changes from RFC2464, "Transmission
>    of IPv6 Packets over Ethernet Networks ".  Numbers identify the
>    Internet-Draft version that the change was made.:

There is a question about this:
> 4.  Stateless Autoconfiguration
> 
>    The default approach to create stable Interface Identifiers
>    [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet
>    interface should be based on [RFC7217].
> 
>    It is not recommended that Interface Identifiers for an Ethernet
>    interface be based on stable IEEE MAC-layer addresses. 

The question is the following: in case I manually change the MAC address 
on the interface, will SLAAC form a new address based on that MAC 
address that I create?

I am not asking whether it is recommended or not (because I understand 
the above text recommends against MAC-in-IP).  But I am asking whether 
or not when I manually change the MAC address will SLAAC generate a new 
address?

By 'MAC address' I mean a 48bit number that can be generated out of the 
blue (1234...), or can be even starting with an OUI reserved in oui.txt.

Alex

Le 09/01/2017 à 21:24, Bob Hinden a écrit :
> Hi,
> 
> I published a new version of rfc2464bis <draft-hinden-6man-rfc2464bis-01>.  Links below.
> 
> This draft brings in the two updates and errata.  The changes include:
> 
>        Incorporate update from draft-ietf-6man-default-iids
>        (currently in RFC Editor queue).  Revised Section 4 to say
>        IIDs should be formed based on RFC7217 and that it not
>        recommended to use hardware based IIDs.
> 
>        Incorporate update from RFC6085.  Added to Section 7 that an
>        IPv6 multicast packet may be mapped to a unicast Ethernet
>        Link layer address and that nodes receiving packets with this
>        address mapping should not drop these packets.
> 
>        Updates to resolve the open Errata on RFC2464.  These are:
> 
>                Errata ID: 430: Correct reference to EUI-64.  Note, the
>                corrected URL specified in the Errata isn't working, the
>                reference now points to one that does work.
> 
>                Errata ID: 4855: This errata is not correct, and will be
>                marked as rejected.  No change is required.  Also, the
>                text that this Errata proposed to change was removed when
>                the update from draft-ietf-6man-default-iids was
>                incorporated.
> 
>        Editorial changes.
> 
> A diff from the previous version can be found at:
> 
>     https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc2464bis-01.txt
> 
> I plan to send separate emails on each update, explaining the changes and asking a few questions.
> 
> This is part of the project to move the core IPv6 specifications to Internet Standard.
> 
> Thanks,
> Bob
> 
>>
>> A new version of I-D, draft-hinden-6man-rfc2464bis-01.txt
>> has been successfully submitted by Robert M. Hinden and posted to the
>> IETF repository.
>>
>> Name:		draft-hinden-6man-rfc2464bis
>> Revision:	01
>> Title:		Transmission of IPv6 Packets over Ethernet Networks
>> Document date:	2017-01-09
>> Group:		Individual Submission
>> Pages:		9
>> URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc2464bis-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-rfc2464bis/
>> Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-rfc2464bis-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc2464bis-01
>>
>> Abstract:
>>    This document specifies the frame format for transmission of IPv6
>>    packets and the method of forming IPv6 link-local addresses and
>>    statelessly autoconfigured addresses on Ethernet networks.  It also
>>    specifies the content of the Source/Target Link-layer Address option
>>    used in Router Solicitation, Router Advertisement, Neighbor
>>    Solicitation, Neighbor Advertisement and Redirect messages when those
>>    messages are transmitted on an Ethernet.
>>
>>    This document replaces RFC 2464 "Transmission of IPv6 Packets over
>>    Ethernet Networks", which will become historic.
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------