On Tue, 13 Nov 2012, Mattia Rossi wrote:
I still like the idea of a led which is red if no prefix could be received,
orange if a /64 has been assigned, and a prefix has been requested from a
downstream router (no prefix for the downstream router), and green if a
prefix < /64 has been assigned
On Nov 13, 2012, at 9:50 AM, Mattia Rossi
wrote:
> I still like the idea of a led which is red if no prefix could be received,
> orange if a /64 has been assigned, and a prefix has been requested from a
> downstream router (no prefix for the downstream router), and green if a
> prefix < /64 ha
Am 13.11.2012 15:14, schrieb Ted Lemon:
On Nov 13, 2012, at 2:24 AM, Brian E Carpenter
wrote:
even if it's the equivalent
of the beeping from a smoke detector whose battery is fading.
To which the typical response is to throw the damned thing through the window
out of rage after it's been be
On Nov 13, 2012, at 2:24 AM, Brian E Carpenter
wrote:
> even if it's the equivalent
> of the beeping from a smoke detector whose battery is fading.
To which the typical response is to throw the damned thing through the window
out of rage after it's been beeping for a couple of hours.
No, there
Mark,
I agree with what you say but that still means RPL could be on the
table. It seems quite feasible to me that we could have a multi-link
route-over subnet using a routing protocol such as RPL with downstream
border routers as well. This may seem unlikely with an LLN but is more
feasible
+1 to Brian. Falling back to the user left with a broken connection and
no feedback is not acceptable. Short cryptic messages may be terse at
the point of origin but there is no lack of resources on the internet to
elucidate them.
Robert
On 13/11/2012 8:24 AM, Brian E Carpenter wrote:
On 12/
On 12/11/2012 17:33, Mark Townsley wrote:
> Nice to see a constructive thread with suggested text for the editors of the
> homenet arch, thank you.
>
> I'm concerned with any "issue a warning" type suggestions though. We are
> working hard to develop automatic configuration that assumes there is
> "Mark" == Mark Townsley writes:
Mark> I'm concerned with any "issue a warning" type suggestions
Mark> though. We are working hard to develop automatic configuration
Mark> that assumes there is no operator involved here. If there is
Mark> no operator to configure our protocol
Nice to see a constructive thread with suggested text for the editors of the
homenet arch, thank you.
I'm concerned with any "issue a warning" type suggestions though. We are
working hard to develop automatic configuration that assumes there is no
operator involved here. If there is no operato
On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote:
>
> On 09/11/2012 7:56 PM, Michael Richardson wrote:
>> (and that's why RPL isn't on the table at homenet)
> Why not? Again, the sort of networks which would use RPL (LLNs) are
> referred to in the charter.
In the charter, LLNs are referred to
> "Mattia" == Mattia Rossi writes:
Mattia> to the following text:
Mattia> The home network needs to be adaptable to such ISP policies, and
thus
Mattia> make no assumptions about the stability of the prefix received from
Mattia> an ISP, or the length of the prefix that may be
> "Mattia" == Mattia Rossi writes:
Mattia> to the following text:
Mattia> The home network needs to be adaptable to such ISP policies, and
thus
Mattia> make no assumptions about the stability of the prefix received from
Mattia> an ISP, or the length of the prefix that may be
> "Andrew" == Andrew McGregor writes:
Andrew> Proxy-ND doesn't seem hard... much less evil than NAT, after all.
I concur. I am not sure why there has been so much concern about it.
--
Michael Richardson
-on the road-
pgpQnOnK8v3On.pgp
Description: PGP signature
___
> "mike" == mike writes:
Michael> Does that apply to my Android phone too?
>>
>> Are you asking if your Android phone, when it gets only /64 from LTE/3G
>> provider, should hand that out, and then indicate "out of /64s"? Yes.
>>
>> The phone has a pretty clear way t
If I'm the downstream router, I can't get a prefix, of course I issue warning
message. However, if I'm the one who still get an /64 and works fine as a leaf,
I won't issue an warning message for a fore-coming downstream router attached
to me.
So you have to implement a check and some sort of
Op 10 nov. 2012, om 00:30 heeft mike het volgende geschreven:
> On 11/9/12 3:21 PM, Michael Richardson wrote:
>>> "Michael" == Michael Thomas writes:
>> >> An ISP that gives out a single /64 is broken. As long as we have
>> >> a way to indicate "out of /64s" (because that could happ
Cameron Byrne wrote:
On Nov 9, 2012 3:30 PM, "mike" mailto:m...@mtcc.com>> wrote:
This case is looked at in v6ops
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03
The simple answer is that there is a deployment lag issue. Neither
Android nor the mobile networks support PD today. But
Proxy-ND doesn't seem hard... much less evil than NAT, after all.
Andrew
On 9/11/2012, at 2:56 PM, Michael Richardson wrote:
>
>> "Andrew" == Andrew McGregor writes:
>Andrew> This whole thread is making me think that specifying that we
>Andrew> use either babel (with attention to
On Nov 9, 2012 3:30 PM, "mike" wrote:
>
> On 11/9/12 3:21 PM, Michael Richardson wrote:
>>>
>>> "Michael" == Michael Thomas writes:
>>
>> >> An ISP that gives out a single /64 is broken. As long as we have
>> >> a way to indicate "out of /64s" (because that could happen, even
>
On 09/11/2012 7:56 PM, Michael Richardson wrote:
(and that's why RPL isn't on the table at homenet)
Why not? Again, the sort of networks which would use RPL (LLNs) are
referred to in the charter.
___
homenet mailing list
homenet@ietf.org
https:
On 11/9/12 3:21 PM, Michael Richardson wrote:
"Michael" == Michael Thomas writes:
>> An ISP that gives out a single /64 is broken. As long as we have
>> a way to indicate "out of /64s" (because that could happen, even
>> if you are given a /48, and have some pathology...), then
> "Michael" == Michael Thomas writes:
>> An ISP that gives out a single /64 is broken. As long as we have
>> a way to indicate "out of /64s" (because that could happen, even
>> if you are given a /48, and have some pathology...), then we are
>> good.
Michael> Does that a
> "Teco" == Teco Boot writes:
Mattia> So what happens if the "lightswitch guys" want to plug-in a
Mattia> router, which they have to, as they can't bridge, but
Mattia> there's only one exit router from one ISP which is managed
Mattia> and gets a /64 only? SLAAC relay? I think
> "Andrew" == Andrew McGregor writes:
Andrew> This whole thread is making me think that specifying that we
Andrew> use either babel (with attention to getting it documented
Andrew> properly) or one of the OSPFv4 MANET extensions, in the case
Andrew> where we have only a /64 an
> I note that the Apple Airport Utility pops up warnings about various
> errors, some of which relate to sub-optimal network configuration,
> rather than misconfiguration. In particular, they warn you if you try
> to use double NAT.
it seems to me that we ought to ask Apple^WStuart how these wa
On 11/08/2012 10:58 AM, Michael Richardson wrote:
An ISP that gives out a single /64 is broken. As long as we have a way
to indicate "out of /64s" (because that could happen, even if you are
given a /48, and have some pathology...), then we are good.
Does that apply to my Android phone too?
M
Op 9 nov. 2012, om 09:00 heeft Mattia Rossi het volgende geschreven:
> Am 08.11.2012 20:04, schrieb Michael Richardson:
>>> "Mattia" == Mattia Rossi writes:
>> >> In a lot of these conversations, the "lightswitch guys" (as
>> >> someone called the LLN proponents) seem to get forgotte
Sent from Hans' iPad2
On Nov 9, 2012, at 4:20 PM, "Mattia Rossi"
wrote:
> Am 08.11.2012 21:03, schrieb Hans Liu:
>> On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote:
>>> On 8 Nov 2012, at 14:28, Ted Lemon wrote:
Sure, but "log a system management error" is not something that a home
>>
Am 08.11.2012 21:03, schrieb Hans Liu:
On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote:
On 8 Nov 2012, at 14:28, Ted Lemon wrote:
Sure, but "log a system management error" is not something that a home router vendor can
meaningfully implement, unless it puts a speaker in the home router and
Am 08.11.2012 21:40, schrieb Robert Cragie:
Just to be clear - using a /64 will not necessarily break a home
network with a LLN. It's just that some kludge will be needed and the
least preferable IMHO for LLNs is bridging.
Yes, I agree, and you can't force the LLN routers to be some high-end
Am 08.11.2012 20:04, schrieb Michael Richardson:
"Mattia" == Mattia Rossi writes:
>> In a lot of these conversations, the "lightswitch guys" (as
>> someone called the LLN proponents) seem to get forgotten.
Mattia> So what happens if the "lightswitch guys" want to plug-in a
On 08/11/12 21:44, Ted Lemon wrote:
On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
I see no reason not to do this... we'd have to have just about as much
information to bridge successfully, and a few hundred routes is no big deal.
+1
I realize that I've been arguing for a different solu
On Nov 8, 2012, at 4:44 PM, Ted Lemon wrote:
> On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
>> I see no reason not to do this... we'd have to have just about as much
>> information to bridge successfully, and a few hundred routes is no big deal.
Is a few hundred enough to meet the presen
On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
> I see no reason not to do this... we'd have to have just about as much
> information to bridge successfully, and a few hundred routes is no big deal.
+1
I realize that I've been arguing for a different solution, but I agree that
this is bett
Oops, meant to reply to the list the first time...
I see no reason not to do this... we'd have to have just about as much
information to bridge successfully, and a few hundred routes is no big deal.
Andrew
On 8/11/2012, at 3:49 PM, Acee Lindem wrote:
> Independent of the routing protocol, I d
Independent of the routing protocol, I don't think we want to inject a /128
advertisement for every device in the homenet into the homenet routing domain.
Acee
On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote:
> This whole thread is making me think that specifying that we use either babel
> (w
Can this be generalized for anytime a prefix offered is not large enough
to cover the number of interfaces?
On 11/8/12 3:40 PM, "Robert Cragie" wrote:
>Just to be clear - using a /64 will not necessarily break a home network
>with a LLN. It's just that some kludge will be needed and the least
Just to be clear - using a /64 will not necessarily break a home network
with a LLN. It's just that some kludge will be needed and the least
preferable IMHO for LLNs is bridging.
So I would suggest something like:
"The home network needs to be adaptable to such ISP policies, and thus
make no
This whole thread is making me think that specifying that we use either babel
(with attention to getting it documented properly) or one of the OSPFv4 MANET
extensions, in the case where we have only a /64 and perhaps any time we find
we have an 802.11s, ad-hoc or NBMA interface in play. That wa
On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote:
>
> On 8 Nov 2012, at 14:28, Ted Lemon wrote:
>>
>> Sure, but "log a system management error" is not something that a home
>> router vendor can meaningfully implement, unless it puts a speaker in the
>> home router and has it start bellowing "ou
On Nov 8, 2012, at 2:40 PM, Ray Bellis wrote:
> I note that the Apple Airport Utility pops up warnings about various errors,
> some of which relate to sub-optimal network configuration, rather than
> misconfiguration. In particular, they warn you if you try to use double NAT.
This is very cool
On 8 Nov 2012, at 14:28, Ted Lemon wrote:
>
> Sure, but "log a system management error" is not something that a home router
> vendor can meaningfully implement, unless it puts a speaker in the home
> router and has it start bellowing "out of addresses" in every known language.
>
> But the rea
On Nov 8, 2012, at 2:11 PM, Michael Richardson wrote:
> interfaces, the IPv6 CE router SHOULD log a system management
> error.
>
> it doesn't tell us to start bridging.
Sure, but "log a system management error" is not something that a home router
vendor can meaningfully impl
> "Brian" == Brian E Carpenter writes:
>> Yes please. I think some ISPs *need* to get a signal like this.
Brian> Sure, but that does *not* excuse us from specifying how the
Brian> end user gets service in such a situation.
so, lets' say you come home with a new fancy router... a
> "Leddy," == Leddy, John writes:
Leddy> What would happen today if a /64 showed up? Why change that
Leddy> behavior?
An RFC6204 router with a single LAN interface is perfectly happy getting
a /64.
An RFC6204 router with more than one LAN interface that doesn't get
enough address s
> "Mattia" == Mattia Rossi writes:
Mattia> might become:
Mattia> The home network needs to be adaptable to such ISP
Mattia> policies, and thus make no assumptions about the stability
Mattia> of the prefix received from an ISP, or the length of the
Mattia> prefix that ma
> "Mattia" == Mattia Rossi writes:
>> In a lot of these conversations, the "lightswitch guys" (as
>> someone called the LLN proponents) seem to get forgotten.
Mattia> So what happens if the "lightswitch guys" want to plug-in a
Mattia> router, which they have to, as they can't
> "Brian" == Brian E Carpenter writes:
Brian> Also consider a dual-homed homenet where one ISP gives a /64
Brian> and the other gives a /56. I guess that has to revert to
Brian> bridging mode too.
no. Let's let the /56 work well, and let the /64-ISP break.
--
Michael Richardso
An ISP that gives out a single /64 is broken. As long as we have a way
to indicate "out of /64s" (because that could happen, even if you are
given a /48, and have some pathology...), then we are good.
A home may have multiple ISPs, and people are gonna notice that some of
them work better than
Mat,
That looks good to me, I hope the architecture authors will pick it up.
Brian
On 08/11/2012 16:15, Mattia Rossi wrote:
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poise
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-powered sensor netw
On 08/11/2012 15:09, Victor Kuarsingh wrote:
>>> even though this would destroy the benefits of subnetting.
>> I think it is arguable whether bridging is the least damaging
>> solution. It fundamentally does not work with route-over multi-link
>> subnets and would therefore require some extra L2
Also consider a dual-homed homenet where one ISP gives a /64 and the
other gives a /56. I guess that has to revert to bridging mode too.
I was going to suggest a solution, where the router within the homenet
simply asks for a DHCP-PD, and if it gets one it keeps routing,
otherwise it
What would happen today if a /64 showed up? Why change that behavior?
On 11/8/12 10:09 AM, "Victor Kuarsingh" wrote:
>
>>> even though this would destroy the benefits of subnetting.
>>I think it is arguable whether bridging is the least damaging
>>solution. It fundamentally does not work with
>> even though this would destroy the benefits of subnetting.
>I think it is arguable whether bridging is the least damaging
>solution. It fundamentally does not work with route-over multi-link
>subnets and would therefore require some extra L2 weirdness at a LLN
>border router. If ISPs are goin
HI,
> So let's just say that giving a single /64 to the home is incompatible with
> homenet architecture, and we need more addresses. I'm fine with that.
Yes please. I think some ISPs *need* to get a signal like this.
Sander
___
homenet mailing list
h
Comment inline.
Robert
On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
Fine, but when such an end customer buys a second router and plugs it in,
will she get an error message that says "Please find a
On 08/11/2012 13:41, Mikael Abrahamsson wrote:
> On Thu, 8 Nov 2012, Robert Cragie wrote:
>
>> In a lot of these conversations, the "lightswitch guys" (as someone
>> called the LLN proponents) seem to get forgotten.
>
> So let's just say that giving a single /64 to the home is incompatible
> with
On 08/11/2012 13:45, Mattia Rossi wrote:
>
>> On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
>>> On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
> Fine, but when such an end customer buys a second router and plugs
> it in,
> will
On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
Fine, but when such an end customer buys a second router and plugs
it in,
will she get an error message that says "Please find a new ISP"?
In this cas
On Thu, 8 Nov 2012, Robert Cragie wrote:
In a lot of these conversations, the "lightswitch guys" (as someone
called the LLN proponents) seem to get forgotten.
So let's just say that giving a single /64 to the home is incompatible
with homenet architecture, and we need more addresses. I'm fine
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-powered sensor n
On Nov 8, 2012, at 7:25 AM, Brian E Carpenter
wrote:
> Without some fundamental surgery on the IPv6 specs, I fear that is true,
> so does it have to become (gulp) a feature of the homenet architecture?
I think it does, or the architecture becomes irrelevant because no-one will be
brave enough t
On 08/11/2012 12:05, Ted Lemon wrote:
> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
> wrote:
>> Fine, but when such an end customer buys a second router and plugs it in,
>> will she get an error message that says "Please find a new ISP"?
>
> In this case I think our only option is to fall back
64 matches
Mail list logo
