Hi,
I just realized that the permanent interface identifier of my MAC has
changed after upgrading to OS 10.12 (I guess).
The output of ifconfig shows a new "secured" flag at the permanent address.
$ ifconfig en0 | grep inet6 | \
> sed "s/2[^:]*:[^:]*:[^:]*:[^:]*:/:/"
inet6 fe80::c54:6333:ac
On 2016-12-14 11:55, Holger Zuleger wrote:
> Hi,
>
> I just realized that the permanent interface identifier of my MAC has
> changed after upgrading to OS 10.12 (I guess).
>
> The output of ifconfig shows a new "secured" flag at the permanent address.
> $ ifconfig en0 | grep inet6 | \
>> se
> On 14 Dec 2016, at 10:55, Holger Zuleger wrote:
>
> Hi,
>
> I just realized that the permanent interface identifier of my MAC has
> changed after upgrading to OS 10.12 (I guess).
>
> The output of ifconfig shows a new "secured" flag at the permanent address.
> $ ifconfig en0 | grep inet6 | \
Hi Jeroen,
>> I found two or three posts in the internet, all mentioning (or hoping)
>> that this is related to a change to RFC7217 as default IID mechanism.
>>
>> But one guy sad, that the source code (of 10.11) shows, that this is a
>> cryptographic generated interface identifier for SeND (RFC39
Thanks Mat,
> man ifconfig says:
>
> " insecure
> Disable the processing of Secure Neighbor Discovery (SEND).
>
> -insecure
> Do not disabled the processing of Secure Neighbor Discovery
> (SEND).”
I thought, that "secured" means, that -insecure is set.
B
Hi,
> On 14 Dec 2016, at 11:08, Jeroen Massar wrote:
>
> On 2016-12-14 11:55, Holger Zuleger wrote:
>> Hi,
>>
>> I just realized that the permanent interface identifier of my MAC has
>> changed after upgrading to OS 10.12 (I guess).
>>
>> The output of ifconfig shows a new "secured" flag at th
On 2016-12-14 12:25, Holger Zuleger wrote:
> Hi Jeroen,
>
>>> I found two or three posts in the internet, all mentioning (or hoping)
>>> that this is related to a change to RFC7217 as default IID mechanism.
>>>
>>> But one guy sad, that the source code (of 10.11) shows, that this is a
>>> cryptogr
> Interesting - I’d also assumed the new form of address was RFC 7217
Yes, especially as draft-ietf-6man-default-iids recommends this as
default generation scheme.
> support. I don’t think any other common OS implements SeND, does it?
Not that I'm aware of, so I was on the way to bury the idea of
On 2016-12-14 12:40, Jeroen Massar wrote:
[..]
>> There is another sysctl parameter (opmode) but unclear what 1 (or 0) means:
>> $ sysctl net.inet6.send
>> net.inet6.send.opstate: 1
>> net.inet6.send.opmode: 1
>
> There is no documentation at all about these things, hence, nothing one
> can say ab
[..]
> Actually, it is not a stable address as some have found out (read:
> anecdotal), they also change at re-install and there are a couple of
> other possibilities from what I recall.
>From xnu-3248.60.10/bsd/netinet6/in6_ifattach.c:
8<
/*
* Generate a last-resort interfac
On 2016-12-14 13:10, Jeroen Massar wrote:
> [..]
>> Actually, it is not a stable address as some have found out (read:
>> anecdotal), they also change at re-install and there are a couple of
>> other possibilities from what I recall.
>
> From xnu-3248.60.10/bsd/netinet6/in6_ifattach.c:
And after
Holger Zuleger writes:
> It seems that some implementation for Linux exist, and also an Windows
> Application (see page 23 on
> http://www.rmv6tf.org/wp-content/uploads/2012/11/IPv6_SeND_PPT1.pdf)
And the slides lead to:
https://github.com/TrustRouter/TrustRouter
"TrustRouter will be available
On 2016-12-14 13:26, Jeroen Massar wrote:
> On 2016-12-14 13:10, Jeroen Massar wrote:
>> [..]
>>> Actually, it is not a stable address as some have found out (read:
>>> anecdotal), they also change at re-install and there are a couple of
>>> other possibilities from what I recall.
>>
>> From xnu-32
On 14 Dec 2016, at 11:45, Holger Zuleger wrote:
support. I don’t think any other common OS implements SeND, does
it?
Not that I'm aware of, so I was on the way to bury the idea of secure
neighbor discovery.
It seems that some implementation for Linux exist, and also an Windows
Application (see
On 12/14/2016 08:08 AM, Jeroen Massar wrote:
> On 2016-12-14 11:55, Holger Zuleger wrote:
>> Hi,
[]
>
> As then you only get the DHCPd address (requires DHCPv6 server) on
> your interface and not all the other magic ones that change all the time
> and are extremely useless if you want to A
On 12/14/2016 08:25 AM, Holger Zuleger wrote:
>>> Has anyone more information about this? Especially how to configure it?
>>
>> The only trick I found out was:
>>
>> https://twitter.com/tweetsix/status/77861562571649
>> 8<---
>> Also who has typed: "sudo sysctl -w net.inet6.ip6.maxifprefixe
On 12/14/2016 08:31 AM, Tim Chown wrote:
> Hi,
>
>> On 14 Dec 2016, at 11:08, Jeroen Massar wrote:
>>
>> On 2016-12-14 11:55, Holger Zuleger wrote:
>>> Hi,
>>>
>>> I just realized that the permanent interface identifier of my MAC has
>>> changed after upgrading to OS 10.12 (I guess).
>>>
>>> The
On 12/14/2016 08:40 AM, Jeroen Massar wrote:
> On 2016-12-14 12:25, Holger Zuleger wrote:
>> Hi Jeroen,
>>
I found two or three posts in the internet, all mentioning (or hoping)
that this is related to a change to RFC7217 as default IID mechanism.
But one guy sad, that the sourc
On 12/14/2016 05:07 PM, Bjoern A. Zeeb wrote:
> On 14 Dec 2016, at 11:45, Holger Zuleger wrote:
>
>>> support. I don’t think any other common OS implements SeND, does it?
>> Not that I'm aware of, so I was on the way to bury the idea of secure
>> neighbor discovery.
>>
>> It seems that some implem
>> My info is, to set
>> sysctl -w net.inet6.send.opstate=0
>> to go back to mac address based eui64, but didn't checked it.
>
> Please don't resort to eui64. That's a bad idea. See RFC7721 and RFC707
Hmm, yes but from an operating view...
In case of re-numbering your network, RFC72177217 (
On 16/12/2016 00:12, Holger Zuleger wrote:
>
>>> My info is, to set
>>> sysctl -w net.inet6.send.opstate=0
>>> to go back to mac address based eui64, but didn't checked it.
>>
>> Please don't resort to eui64. That's a bad idea. See RFC7721 and RFC707
> Hmm, yes but from an operating view...
>
21 matches
Mail list logo