Grande Fromage), but if that's the direction from which rough
consensus will emerge... well, okay then. Let's open up the bag.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
homenet mailing list
homenet@ietf.org
for use by globally reachable nodes on the interior network.
Does that about cover it?
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo
link, the
DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN
accordingly.
I'm not sure this model can be made to work with IPv6, but I wouldn't put it
past the telcos to try.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
should be counted.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote:
If a cell phone operator gives you a single /64, what do you propose to do?
If a certain CableLabs MSO gives each of its several tens of millions of
Internet users in North America only a single /64, what do we propose to do?
--
james
with big data
centers in the proverbial cloud. Yes, that means that you're relying on
Internet service to be constantly available to resolve service locations on
your local home network, but it does seem to work reasonably well today.
--
james woodyatt j...@apple.com
member of technical staff
in the towel on E2E and go with RFC 6092 on by
default at the border gateway. It should be silent about PCP until something
can be done about its lack of explicit support for nested security domains.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
do exactly that with
their home networks using their own DNS servers. Check out
http://www.dns-sd.org/ClientSetup.html for more details.
Also, I too think this discussion is off topic for HOMENET.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
[*] c.f.
http
to the hostname part of the service resources.
Step p4 above starts parallel TCP connections to one or more of the destination
addresses returned by the locate operation, in a sensible order and possibly in
parallel, until one of them connects or they all fail.
--
james woodyatt j...@apple.com
to talk
about forward DNS coherently.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
that different from those of anyone else in the application/security
community. Can we skip past the part when I enumerate them again?
I guess I had hoped the HOMENET group would more easily find consensus around
addressing this promptly, but that may have been wishful thinking.
--
james woodyatt j
space does today.
I mean, nothing bad would happen, right?
What does the conditional phrase if necessary mean in your mind? Under what
circumstances do you imagine this would not be necessary for operational
continuity?
--
james woodyatt j...@apple.com
member of technical staff, core os
On Aug 28, 2012, at 17:42 , Mark Andrews ma...@isc.org wrote:
Repeat until you have the entire 128 bits for all registered nodes in the /48.
You shouldn't expect to get the temporary addresses. Only the persistent ones,
and some nodes-- particularly the ones that host only clients and no
question should be, NAME
ALL THE THINGS IN DNS!! What am I missing?
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
://tools.ietf.org/html/draft-sekar-dns-ul
http://tools.ietf.org/html/draft-sekar-dns-llq
Maybe HOMENET could push for these to be taken up as IETF work items?
--
james woodyatt j...@apple.com
member of technical staff, core os networking
for it?
Can we strengthen HOMENET arch to deprecate NPT66 explicitly?
--
james woodyatt j...@apple.com
core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
when you consider corporate VPN's.
Actually, VPN is usually just a special case of MIF, i.e. individual hosts are
multihomed, not the whole homenet. This is a much simpler situation to manage,
and solutions for that space are already ubiquitous.
--
james woodyatt j...@apple.com
core os
On Oct 23, 2012, at 01:29 , Ray Bellis ray.bel...@nominet.org.uk wrote:
On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote:
I would say that it MUST be deprecated by the arch document.
The arch document is Informational and contains no RFC 2119 keywords.
My email to the list
.
--
james woodyatt j...@apple.com
core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Oct 26, 2012, at 24:29 , Teco Boot t...@inf-net.nl wrote:
Opinions?
Seems like a straight-up job for IPsec, which is why RFC 6092 has section 3.2.4
IPsec and Internet Key Exchange (IKE).
--
james woodyatt j...@apple.com
core os networking
is confined to the local link.)
Maybe I'm missing something, but I think this is really an intractable problem,
given what I know about it.
--
james woodyatt j...@apple.com
core os networking
___
homenet mailing list
homenet@ietf.org
https
to communicate directly with one
another. Neither alternative seems very practical to me.
this has been discussed on this list extensively.
Without apparent resolution or the production of a draft as far as I can see.
Hence my ongoing skepticism about this usage scenario.
--
james woodyatt j
On Nov 15, 2012, at 04:26 , Ted Lemon mel...@fugue.com wrote:
On Nov 14, 2012, at 10:41 PM, james woodyatt j...@apple.com wrote:
However notionally easy this problem is to address, I imagine that practical
matters, at some point, must rise to the top of the pile of points to
consider
could be mapped 1:1 into
the new prefix. Now we have RFC 6177, which explodes all of that, for
basically no sensible reason that I can see, and we are all the poorer for it.
Well done, V6OPS, well done.
--
james woodyatt j...@apple.com
core os networking
at reasonable price. This all happened before, and we're not
showing any signs of making sure it doesn't happen again.
--
james woodyatt j...@apple.com
core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Feb 25, 2013, at 16:28 , Lorenzo Colitti lore...@google.com wrote:
On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt j...@apple.com wrote:
As a result, it means that Automatic Prefix Management here is basically
unable to do it statelessly, i.e. by randomly generating subnet numbers from
to do it.
--
james woodyatt j...@apple.com
core os networking
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Tue, Oct 7, 2014 at 5:32 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 08/10/2014 12:14, James Woodyatt wrote:
The requirements keywords in this section make for a pretty serious
interop
clash with Thread networks http://threadgroup.org/, which generate
their
own ULA
On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg markus.stenb...@iki.fi
wrote:
On 8.10.2014, at 2.14, James Woodyatt j...@nestlabs.com wrote:
The requirements keywords in this section make for a pretty serious
interop clash with Thread networks http://threadgroup.org/, which
generate
it be helpful if I tried to write up a proposed set of edits for this?
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister pierre.pfis...@darou.fr
wrote:
But I’m going to change it and making it more clear that authorities can
provide their own prefixes. Even ULAs.
Thanks! I'm very pleased to see this agreement.
--
james woodyatt j...@nestlabs.com
Nest Labs
services are
provisioned, configured and operational, i.e. there shall always be at
least one preferred global scope network prefix, and there shall be an
autonomously generated local prefix available as a last resort whenever
there are no valid delegated prefixes.
--
james woodyatt j...@nestlabs.com
rehashing that discussion.
If we're going to go with HOMENET always generating a ULA prefix at network
commissioning time and persisting for the life of the network, then I'm
going to need to understand better how we're handling network joins and
splits.
--
james woodyatt j...@nestlabs.com
Nest Labs
expire if the objective is for a ULA prefix to be invariant. So how many
times can a network join with others before it runs out of space for
deprecated and redundant but unexpired and invariant ULA prefixes?
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
this is perhaps not worth the effort, and I won't argue further
for it.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
with the same ULA prefix,
that prefix will collide with existing previously commissioned networks at
the exterior domain gateway.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https
not recommend transparency as the default
operating mode of residential gateway firewalls. And very few in actual
deployments are transparent by default. So this can't be expected to work
even with GUA instead of ULA.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
On Fri, Oct 17, 2014 at 12:54 PM, Ted Lemon mel...@fugue.com wrote:
On Oct 17, 2014, at 2:49 PM, James Woodyatt j...@nestlabs.com wrote:
As I recall, the proposals in your response were less than concrete and
didn't solve the problems. In particular, I remain curious about how to
expire
On Tue, Oct 14, 2014 at 3:28 PM, Ted Lemon mel...@fugue.com wrote:
On Oct 14, 2014, at 5:14 PM, James Woodyatt j...@nestlabs.com wrote:
But there is a problem with only deprecating prefixes without expiring
them. If they never expire, then they accumulate without limit within
existing
On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon mel...@fugue.com wrote:
On Oct 20, 2014, at 2:00 PM, James Woodyatt j...@nestlabs.com wrote:
Okay... except it seems you're admitting that my scenario where a simple
reconfiguration of a network topology, e.g. one caused by an intermittent
RF
concerns. Nevertheless, I shall stop arguing my case, and I
will accept that I've lost it.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
will be
followed.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Wed, Oct 22, 2014 at 11:04 AM, Michael Richardson mcr+i...@sandelman.ca
wrote:
James Woodyatt j...@nestlabs.com wrote:
My assertion:
Given HNCP generated one spans whole administrative domain, _and_
should not have routing anywhere outside it, it’s uniqueness does
On Wed, Oct 22, 2014 at 12:51 PM, Ted Lemon mel...@fugue.com wrote:
On Oct 22, 2014, at 2:46 PM, James Woodyatt j...@nestlabs.com wrote:
They may often be the only *default* routers, but there can be— and
absolutely definitely will be in the vast majority of cases— overlay
networks
/homenet
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
of at least one other serious proposal to use NPTv6 in a
shipping home gateway. It would be easier to argue against it if those RFC
6092 filters weren't installed everywhere.)
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
this isn't a controversial
statement.
--
james woodyatt j...@nestlabs.com
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Aug 18, 2015, at 10:45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
Section 6.1 says:
A node MUST be able to detect whether two of its local internal
interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both local
On Aug 18, 2015, at 06:38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
Section 6.1 says:
A node MUST be able to detect whether two of its local internal
interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both
On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com wrote:
On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch to...@isi.edu wrote:
DAD is also needed to detect duplicates due to host misconfiguration,
such as when a cloned MAC is added to the same network or when addresses
are duplicated by
On Aug 6, 2015, at 17:42, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
I wasn't aware of the treatment of multicast packets as less than best
effort in wireless transmission. That is not exactly intuitive, given
that radio is inherently broadcast.
Yes, that's
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
On Jul 20, 2015, at 16:17, Ray Bellis r...@bellis.me.uk wrote:
The Chairs would like to ask for advance volunteers for our session
Wednesday afternoon to take notes of the meeting and relay comments from
the jabber room.
I volunteer to relay comments from the Jabber room. Someone else
On Jul 13, 2015, at 04:28, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
Last night, shncpd learned to send RAs. It was a lot of fun.
Bravissimo!
—james
___
homenet mailing list
homenet@ietf.org
On Aug 26, 2015, at 01:07, Dave Taht dave.t...@gmail.com wrote:
Another example of that problem is that it would be nice to have a
standard for fetching what is my uplink/downlink rate from isps.
upnp has some support for propagating this info, but it is underused
and rarely configured
o i don't trust? For whom I'm
> the product? yuck.
>
> Mike
>
> On 11/21/2016 11:34 AM, james woodyatt wrote:
>> On Nov 16, 2016, at 17:31, Michael Richardson <
>> <mailto:mcr+i...@sandelman.ca>mcr+i...@sandelman.ca
>> <mailto:mcr+i...@sandelman.ca>> wr
ng case for doing any of this naming
architecture work.
--james woodyatt <j...@google.com <mailto:j...@google.com>>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
aces are
disabled or bypassed by default.
It’s not about reducing attack surfaces. It’s about making systems that are
safe for deployment in close proximity to humans.
--james woodyatt <j...@google.com <mailto:j...@google.com>>
___
h
hows how they will be reachable directly by
arbitrary public hosts.
I just don’t see how there is any such realistic scenario. Hence, I’m not sold
that adopting this draft is a good idea.
--james woodyatt <j...@google.com>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On 10/26/2017 11:39 AM, Gert Doering wrote:
On Thu, Oct 26, 2017 at 11:32:44AM -0700, james woodyatt wrote:
Accordingly, I strongly recommend that HOMENET dispense with the "My
Friendly ISP" model with extreme prejudice, and adopt what I shall call
the "HOMENET Castle Doctri
On 10/26/2017 08:22 AM, Juliusz Chroboczek wrote:
>On 10/24/2017 07:00 AM, Gert Doering wrote:
>>
I find the model of "there is a CPE, and behind that CPE, I connect
another router to get homenet functionality" a bit unsatisfactory.
I think there are two possible deployment models.
1. The «
62 matches
Mail list logo
