A host SHOULD select a default gateway for each prefix it uses to
obtain one of its own addresses. That router SHOULD be one of the
routers advertising the prefix in its RA. As a result of doing so,
when a host emits a datagram using a source address in one of those
prefixes and has
Am 10.08.2015 um 19:28 schrieb Fred Baker (fred):
In any event, I would urge the HNCP design team to consider the cases, and
either make an argument that making network routing more complex (BCP 84) has
a benefit I'm missing and actually works without the rule, or change HNCP to
not have
On 16/08/2015 21:31, Steven Barth wrote:
Am 10.08.2015 um 19:28 schrieb Fred Baker (fred):
In any event, I would urge the HNCP design team to consider the cases, and
either make an argument that making network routing more complex (BCP 84)
has a benefit I'm missing and actually works without
On Aug 13, 2015, at 8:21 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
I think all we have to do is delete 'on-link' in the second paragraph.
(The 'generally' in the first paragraph allows for the exceptional
case that Mikael was concerned about, I think.)
I'll give people a
On Wed, 12 Aug 2015, Ole Troan wrote:
Mikael,
in the land of contrived examples! :-)
this working groups answer to the below is make this a homenet and run HNCP.
then the host rule enhancement isn’t used.
in any case let me try to reply below, although I’m quite confused about the
example.
On 13/08/2015 17:23, Mikael Abrahamsson wrote:
On Thu, 13 Aug 2015, Brian E Carpenter wrote:
I still don't understand what a host with an IA_NA or IA_PD that isn't
covered by an on-link PIO should do with a packet sourced
from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very
On Aug 13, 2015, at 7:37 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
So I think the -01 draft is wrong, since it says on-link.
What is says is
A host receives prefixes in a Router Advertisement [RFC4861], which
goes on to identify whether they are usable by SLAAC
On 14/08/2015 14:46, Fred Baker (fred) wrote:
On Aug 13, 2015, at 7:37 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
So I think the -01 draft is wrong, since it says on-link.
What is says is
A host receives prefixes in a Router Advertisement [RFC4861], which
goes on
Below...
On 13/08/2015 06:42, Mikael Abrahamsson wrote:
On Wed, 12 Aug 2015, Ole Troan wrote:
For DHCPv6 these contraints do not apply anymore. That's what I'm trying to
figure out, how do we handle these IA_NAs and
IA_PDs that are not within an on-link RA being sent for that prefix.
I
On Thu, 13 Aug 2015, Brian E Carpenter wrote:
I still don't understand what a host with an IA_NA or IA_PD that isn't covered
by an on-link PIO should do with a packet sourced
from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid
case.
I think we're saying: there needs
Mikael,
Your document describes (in my opinion) desireable behaviour for devices
going forward. I would like to see text for DHCPv6 as well, both IA_NA and
IA_PD, if the same kind of behaviour can work there somehow. This is out of
scope for homenet though.
the rule applies regardless
On Wed, 12 Aug 2015, Ole Troan wrote:
Mikael,
Your document describes (in my opinion) desireable behaviour for devices going
forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if
the same kind of behaviour can work there somehow. This is out of scope for
homenet
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote:
Ole, Mikael, could either of you please summarise the discussion you're
having for us mere mortals? I don't understand what problem you're
trying to solve, and I don't understand why you're distinguishing
between SLAAC and DHCPv6.
Because a
Mikael,
Your document describes (in my opinion) desireable behaviour for devices
going forward. I would like to see text for DHCPv6 as well, both IA_NA
and IA_PD, if the same kind of behaviour can work there somehow. This is
out of scope for homenet though.
the rule applies regardless
“In SA, DA, NH selection, prefer the NH that has advertised a PIO
covering the SA”
It took me a while to decode that. If anyone else is as stupid as I am,
here's the translation
When selecting the (source, destination, next-hop) triple among
available routes for a given destination
On Wed, 12 Aug 2015, Ole Troan wrote:
two PIO’s of different length on the link sounds like a configuration
error.
Then I must still be missing something.
Example time:
A B+-+F
+ +
| |
++-++
| |
+ +
C D
Mikael,
For DHCPv6 these contraints do not apply anymore. That's what I'm trying to
figure out, how do we handle these IA_NAs and IA_PDs that are not within an
on-link RA being sent for that prefix.
I take it IA_PD was included above by mistake.
No.
an IA_PD prefix is by definition
Juliusz,
“In SA, DA, NH selection, prefer the NH that has advertised a PIO
covering the SA”
It took me a while to decode that. If anyone else is as stupid as I am,
here's the translation
When selecting the (source, destination, next-hop) triple among
available routes for a given
Mikael,
in the land of contrived examples! :-)
this working groups answer to the below is make this a homenet and run HNCP.
then the host rule enhancement isn’t used.
in any case let me try to reply below, although I’m quite confused about the
example.
two PIO’s of different length on the
Mikael,
Ole, Mikael, could either of you please summarise the discussion you're
having for us mere mortals? I don't understand what problem you're trying
to solve, and I don't understand why you're distinguishing between SLAAC and
DHCPv6.
Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't
Your document describes (in my opinion) desireable behaviour for devices
going forward. I would like to see text for DHCPv6 as well, both IA_NA and
IA_PD, if the same kind of behaviour can work there somehow. This is out of
scope for homenet though.
the rule applies regardless of how the
On Tue, 11 Aug 2015, Ole Troan wrote:
Your document describes (in my opinion) desireable behaviour for devices going
forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if
the same kind of behaviour can work there somehow. This is out of scope for
homenet though.
https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00
Something that homenet, and specifically HNCP, might be interested to consider
is the impact of egress/SADR routing as discussed in this draft on its
recommendations. The draft is in WGLC and in need of a revised draft, so you
On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
I'm not sure if I read you right, but I assume you are concerned about
what happens when a delegated prefix is retraceted. (The ISP stops the
delegation, or the DHCPv6-PD client decides to hide the
Fred,
Add another LAN interface to Alice, connecting host Porky.
If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t
use ISP Bob.
It would be a quite complicated set of rules determining when Alice should or
should not include ISP Bob’s prefixes on a given link. I’m
On Aug 10, 2015, at 10:28, Fred Baker (fred) f...@cisco.com wrote:
If every router is responsible to announce prefixes from ISP-Alice and
ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a
packet to ISP-Alice, it will send it to ISP-Bob, who will then have to
26 matches
Mail list logo
