On Mon, 27 Jul 2015, Juliusz Chroboczek wrote:
During my quick talk on Wednesday, I mentioned that I had been pleasantly
surprised at the very clean interaction between the protocols:
- HNCP redistributes assigned prefixes into the routing protocol;
I was under the impression that
Am 05.08.2015 um 12:12 schrieb Mikael Abrahamsson:
I was under the impression that HNCP/hnetd configured address+prefix on
interfaces which is then picked up by the routing protocol when it looks at
what addresses/prefixes are available on what interfaces. Am I wrong?
No, you aren't.
* Juliusz Chroboczek
After that you can also include the PIO with PL=VL=0 in the periodic
RAs (that you'll presumably be transmitting anyway)
How many PIOs will fit? Is the 1280 octet minimal MTU the only
limitation?
I don't think there's any practical limit, considering that you can
This is why I think it would be great if the deprecated prefix
continued to be sent (in RA and HNCP) until its original valid lifetime
expired.
The problem is that the valid lifetime can be several years so I don't think
that is very practical unless we want to also enforce an upper bound on
This is why I think it would be great if the deprecated prefix
continued to be sent (in RA and HNCP) until its original valid lifetime
expired.
The problem is that the valid lifetime can be several years
Huh? The HNCP implementation controls the valid lifetime it sends, why
would it set it
After that you can also include the PIO with PL=VL=0 in the periodic
RAs (that you'll presumably be transmitting anyway)
How many PIOs will fit? Is the 1280 octet minimal MTU the only limitation?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
For all intents and purposes a deprecated prefix is one with a preferred
lifetime of 0 so that is supported (TLV has valid and preferred lifetimes).
If your ISP does a graceful renumbering than that is what happens, your
RA server just has to play ball here though.
Right, I was wondering what
Hi,
On 27 Jul 2015, at 14:58, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
snip
Renumbering is not as smooth -- it appears to be impossible to remove
a set of addresses wholesale, retracting a set of PIOs merely causes the
old addresses to become deprecated. Since after a
Much will depend if the ISP is offering their customer a ‘graceful’
renumbering event. If they do, then the principle applied in RFC4192
could be applied, and you will have a period where both prefixes (old
and new) co-exist, before the old prefix is removed. In that case, the
older
Much will depend if the ISP is offering their customer a ‘graceful’
renumbering event. If they do, then the principle applied in RFC4192 could
be applied, and you will have a period where both prefixes (old and new) co-
exist, before the old prefix is removed. In that case, the older
Actually RFC 6204 (and its successor 7084) have a requirement that enforces
keeping it in the RA for at least 2h. HNCP makes following 7084 mandatory
atm.
If you're referring to RFC 7084's:
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new
If you're referring to RFC 7084's:
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime
Why don't you set the valid lifetime to 0 as well?
If a new host is connecting to the network while you're advertising the
max(old valid lft, 2h) valid lifetime, it will actually auto-configure
itself with an address from the withdrawn prefix. If you set valid
lifetime to 0, it won't.
* Steven Barth
If a new host is connecting to the network while you're advertising
the max(old valid lft, 2h) valid lifetime, it will actually
auto-configure itself with an address from the withdrawn prefix. If
you set valid lifetime to 0, it won't.
Sounds good, i don't mind. Just have to
* Steven Barth
In an ungraceful case (flash renumbering) we stop announcing the prefix in
HNCP and the individual routers who have assigned it, MUST deprecate it
according to RFC 7084 (not just stop announcing it in RAs). This deprecation
sets preferred lifetime to 0 and valid lifetime to max
During my quick talk on Wednesday, I mentioned that I had been pleasantly
surprised at the very clean interaction between the protocols:
- HNCP redistributes assigned prefixes into the routing protocol;
- HNCP redistributes assigned prefixes into the RA and DHCPv4 servers;
- the routing
On Mon, Jul 27, 2015 at 3:58 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
During my quick talk on Wednesday, I mentioned that I had been pleasantly
surprised at the very clean interaction between the protocols:
- HNCP redistributes assigned prefixes into the routing protocol;
The situation with DHCPv4 is not as satisfactory
[...]
(FORCERENEW is not useful).
Roy Marples, the author of dhcpcd, is telling me to look at RFC 6704.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers,
who makes sure that these are prefixes that are reasonable good
measured by the metric of the routing protocol?
Nobody. From the point of view of the host, all connected routers are
equivalent.
If the host is single-homed,
19 matches
Mail list logo
