Citeren Arjen de Korte :
Citeren Steven Barth :
Is that okay with you or do you see any other issues?
One issue left. Since IPv6 is configured statically here, the
preferred- and valid lifetimes are 'forever' (represented as
0x). If the lifetime is forever, it should stay that wa
Citeren Steven Barth :
Is that okay with you or do you see any other issues?
One issue left. Since IPv6 is configured statically here, the
preferred- and valid lifetimes are 'forever' (represented as
0x). If the lifetime is forever, it should stay that way. See
attached patch. It
Citeren Steven Barth :
Is that okay with you or do you see any other issues?
I'm seeing negative preferred and valid lifetimes:
Mar 30 19:24:46 host.example.com NetworkManager[750]: valid_lft -173
Mar 30 19:24:46 host.example.com NetworkManager[750]:
preferred_lft -173
Mar 30 19:54:
Since I avoid ULA like the plague, this probably won't be a problem
for me and global IPv6 addresses will be served. But I'm not convinced
that favoring a ULA prefix (if available) over an ip6prefix is best at
all times.
Nothing is favored, DHCPv6 just hands out ULAs only (if one is there).
Citeren Steven Barth :
After thinking it through a bit more, I changed the default behavior
to the following:
The preferred lifetime is now as given by the ISP, however the
DHCPv6 server will only hand out the address with the highest
preferred lifetime (= the ULA unless disabled).
Since
After thinking it through a bit more, I changed the default behavior to
the following:
The preferred lifetime is now as given by the ISP, however the DHCPv6
server will only hand out the address with the highest preferred
lifetime (= the ULA unless disabled).
Thus flash renumbering should stil
Steven Barth writes:
>>
>> The problem is that you try to be "smart" by abusing the ability to set
>> the address preferred lifetime lower than T1. I don't dispute that it
>> is allowed by the RFC, but it is definitely not recommended.
> There is no formal requirement (not even a SHOULD) that sa
Citeren Steven Barth :
The problem is that you try to be "smart" by abusing the ability to set
the address preferred lifetime lower than T1. I don't dispute that it
is allowed by the RFC, but it is definitely not recommended.
There is no formal requirement (not even a SHOULD) that says
otherw
On 27.03.2015 10:41, Kevin Darbyshire-Bryant wrote:
On 26/03/2015 23:51, Steven Barth wrote:
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support
downstream delegation and its DHCPv6 features aren't well integrated
if you have a dynamic prefix e.g. delegated from your ISP.
I've be
The problem is that you try to be "smart" by abusing the ability to set
the address preferred lifetime lower than T1. I don't dispute that it
is allowed by the RFC, but it is definitely not recommended.
There is no formal requirement (not even a SHOULD) that says otherwise.
The recommendation
Steven Barth writes:
> If the DHCPv6 server sends values for T1 and / or T2 which are valid
> the client must honor them and not try to be "smart" about lifetimes
> of addresses.
The problem is that you try to be "smart" by abusing the ability to set
the address preferred lifetime lower than T1.
On 26/03/2015 23:51, Steven Barth wrote:
> Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support
> downstream delegation and its DHCPv6 features aren't well integrated
> if you have a dynamic prefix e.g. delegated from your ISP.
I've been messing with the 'constructor' option for quite a
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support
downstream delegation and its DHCPv6 features aren't well integrated if
you have a dynamic prefix e.g. delegated from your ISP.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-de
Citeren Steven Barth :
This breaks clients that need fixed IPs (in my case, mostly webmail
clients).
I wonder why they are so sensitive to source-address changes since
their old address is still valid and not deprecated so there is no
need to switch.
Webmail clients usually don't keep a c
This breaks clients that need fixed IPs (in my case, mostly webmail
clients).
I wonder why they are so sensitive to source-address changes since their
old address is still valid and not deprecated so there is no need to switch.
I would gladly send the DHCPv6 address with 0 preferred lifetime
On 26/03/2015 18:36, Arjen de Korte wrote:
> Citeren Steven Barth :
>
>>> In that case, I have a lot of bug reports to file, because none of
>>> the DHCPv6 clients I tried were happy with preferred lifetimes of 1
>>> second on their leases (which includes Windows 7, 8.1 and openSUSE
>>> 13.2).
>> S
Citeren Steven Barth :
In that case, I have a lot of bug reports to file, because none of
the DHCPv6 clients I tried were happy with preferred lifetimes of 1
second on their leases (which includes Windows 7, 8.1 and openSUSE
13.2).
Sorry, I cannot confirm this. I just tried it with both Win
In that case, I have a lot of bug reports to file, because none of the
DHCPv6 clients I tried were happy with preferred lifetimes of 1 second
on their leases (which includes Windows 7, 8.1 and openSUSE 13.2).
Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and
Debian test
Citeren Steven Barth :
Hello Arjen,
most likely, your DHCPv6 client implementation is faulty and you
should probably file a bug for more than one reason.
In that case, I have a lot of bug reports to file, because none of the
DHCPv6 clients I tried were happy with preferred lifetimes of 1
Hello Arjen,
most likely, your DHCPv6 client implementation is faulty and you should
probably file a bug for more than one reason.
If the DHCPv6 server sends values for T1 and / or T2 which are valid the
client must honor them and not try to be "smart" about lifetimes of
addresses.
Besides
Citeren Arjen de Korte :
I use an IPv6 tunnel provided by Hurricane Electric to provide IPv6
access for my LAN. HE tunnels are configured statically (no DHCPv6 /
PD involved) and for the purpose of understanding what ranges are
used, assume the following:
WAN - 2001:DB8:DEAD:BEEF::/64
I use an IPv6 tunnel provided by Hurricane Electric to provide IPv6
access for my LAN. HE tunnels are configured statically (no DHCPv6 /
PD involved) and for the purpose of understanding what ranges are
used, assume the following:
WAN - 2001:DB8:DEAD:BEEF::/64 (local tunnel endpoint at
22 matches
Mail list logo
