> "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
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 w
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 Aug 13, 2015, at 8:21 PM, Brian E Carpenter
> 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 couple of days to comme
On 14/08/2015 14:46, Fred Baker (fred) wrote:
>
>> On Aug 13, 2015, at 7:37 PM, Brian E Carpenter
>> 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
> On Aug 13, 2015, at 7:37 PM, Brian E Carpenter
> 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 [RFC4862]
[RFC4941] [RFC7
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
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 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 t
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 pref
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
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 li
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 take it IA_PD was included above by mistake.
No.
This is
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_P
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
> On Aug 12, 2015, at 5:44 AM, 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 DH
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 DHC
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
>> “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 pr
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.
t
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 tho
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 appli
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.
the
> 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 th
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 qui
> On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek
> 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 prefix from the
> rest of th
On Aug 10, 2015, at 10:28, Fred Baker (fred) 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
> redirect it to
> The second issue, and this one I'm unsure about but raise in case there
> is an issue, has to do with the process of removing a prefix from
> a network. It seems likely that we have a counterpart to RIP's
> count-to-infinity problem, except that there is no counter to rely
> on. If a router adver
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
may
29 matches
Mail list logo
