On Wed, Oct 28, 2015 at 10:07 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> Fully agreed, but I'm not sure what is the WG's thinking about IPv4. RFC
> 7368 (Homenet arch) is conveniently vague about IPv4. My reading is that
> the authors of RFC 7368 expected that router vendo
Hear, hear!
We have spent far too much time arguing about this, and I am happy we have
a conclusion. A big thank you to the chairs for calling making this call. I
strongly agree that given the dynamics of the home networking market, there
needs to be one, and only one, routing protocol. I don't se
On Wed, Aug 12, 2015 at 11:54 AM, Alia Atlas wrote:
> ECMP is critical in the datacenter and backbone because those networks are
>> designed to provide the E ("equal") in ECMP. Because the links are equal,
>> it's easy to load-balance over them without needing to do complicated stuff
>> like traf
On Mon, Aug 10, 2015 at 5:08 PM, Ray Bellis wrote:
> Whilst not wanting to de-rail any effort to standardise Babel (since I
> firmly believe it should be standardised), I'd like to hear the WG's
> view on having part of our Homenet stack be on Experimental Track
> instead of PS. E.g., would it a
On Sat, Aug 8, 2015 at 11:00 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> I'm confused again. PIO lifetimes are on the order of hours, or even
> days, while unsolicited RAs are sent every 60s. Plus there's nothing
> preventing you from sending them more often.
>
The default
On Mon, Aug 10, 2015 at 4:02 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> [...]
> There are two lessons to be drawn from that experience:
>
> 1. don't put 1500 wifi routers in a single room;
>
> 2. making a routing daemon that works well in a variety of conditions is
>
On Jul 13, 2015 12:28, "Juliusz Chroboczek"
wrote:
> - I'm setting the A flag even for prefix lengths different from /64,
> which is a reasonable thing to do according to my reading of RFC 7421.
What's the point of sending A=1 with a prefix length that's not 64?
___
On Wed, Apr 8, 2015 at 4:23 PM, Ray Hunter wrote:
> Terry - you might consider adding a pointer to RFC 7368 as an explicit source
> of input for the requirements.
>
> +1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That
> should be the baseline for any beauty contest of routing p
On Fri, Apr 3, 2015 at 7:20 AM, Margaret Wasserman
wrote:
> I think we could come closer to this by forming a Babel-specific WG that
> is chartered to take the current Babel documents as a starting point and
> only change them by consensus of the WG to meet IETF standards-track
> requirements and
On Thu, Mar 26, 2015 at 2:00 PM, Mikael Abrahamsson
wrote:
> Just to be pedantic, my comment was completely serious and not a "hint".
>> New implementations almost always suffer from lack of testing of corner
>> cases. Same thing with protocol specs. If something exists to exercise
>> those cases
On Thu, Mar 26, 2015 at 11:11 AM, Terry Manderson wrote:
> For each
> highly plausible candidate routing protocol, the design team will
> estimate the work needed and the associated timeline to get an
> acceptable, full, standardized solution using each protocol.
I find it concerning to say tha
On Thu, Oct 16, 2014 at 8:26 AM, Mark Andrews wrote:
> Unless you have really old stacks your device will pick the new GUA first to
> talk to your jukebox when you are on your neighbor's network and the ULA
> to talk to it when you are on your own.
>
No, it won't. It will pick GUA->GUA both time
On Thu, Oct 16, 2014 at 1:28 AM, Ted Lemon wrote:
> My point was that homenets should have ULAs, and should not use GUAs for
> local communication, because GUAs can be flash renumbered,
Actually, they can't.
http://tools.ietf.org/html/rfc4862#section-5.5.3 paragraph e) 3.
_
On Wed, May 8, 2013 at 7:51 PM, Steven Barth wrote:
> if there would be multiple routers which I guess is unlikely in that
> situation. One could maybe attribute the prefix to the source address of
> the DHCPv6 server but that sounds problematic to me aswell.
>
So you're talking about the case w
On Wed, May 8, 2013 at 7:28 PM, Markus Stenberg wrote:
> IANA application is applicable iff draft is about to go RFC; I'm not
> related to that author in any shape or form, so no clue (not even sure if
> draft is going anywhere, in IETF86 there was muted response at best to it
> if I remember righ
On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson
wrote:
> I don't take this to mean that HOMENET and HIPNET are interoperating?
>
We didn't try that. We expect a contiguous homenet network to work fine
behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET
won't be able to g
John,
Thanks for providing this infrastructure to test on. We were able to
successfully test Markus's implementation and show working
source+destination based routing.
Video or it didn't happen:
http://www.youtube.com/watch?v=3Omg1lJ6EQI&feature=youtu.be
Cheers,
Lorenzo
On Wed, Mar 13, 2013 at
On 9 Mar 2013 17:07, "Brzozowski, John"
wrote:
> Sorry for the late notice. We have some lab/testing space available for
> home networking running code *before* Bits-n-Bytes. I estimate that we
> will be able to get start as early as Tuesday and make the lab available
> until the afternoon befor
On Wed, Mar 6, 2013 at 7:03 AM, STARK, BARBARA H wrote:
> As a home user who currently gets a /64 (via 6rd) from my ISP, I find this
> recommendation insufficient.
Who is the ISP? Do you know why they are only handing out /64? Have you
tried to talk to them?
On Tue, Feb 26, 2013 at 1:13 PM, Mark Andrews wrote:
> > Hmm. Do we know for sure that all clients properly depref ULAs below
> global
> > addresses (either because they follow RFC6724 instead of RFC3484, or
> > because they implement the longest prefix matching rule?) If not, some
> > clients mi
On Tue, Feb 26, 2013 at 7:17 AM, Mark Townsley wrote:
> > Great idea. I won't be in Orlando, but I am fairly sure there is nothing
> > I would do there that cares about address persistency, apart from
> > having to reconnect to jabber maybe. Conducting an RFC 4192 procedure
> > on Tuesday night a
On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote:
> > The alternative is basically a vicious circle: if ISPs ignore the IETF's
> advice and assign a /64 because they see additional address space as an
> upsell opportunity, then someone will figure out how to share the /64 by
> using ugly hacks l
On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt wrote:
> p1. I don't believe it's reasonable to assume that service providers will
> always provide a short enough prefix to number all the links in a
> subscriber's network, or that those that currently do will continue to do
> so into the foresee
On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt 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 an identifier space of conventional size and testing for collision
> before using them
On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter wrote:
> Figure 2 of the architecture is the problematic one, where there are end
> hosts that share the only connection between 2 CERs (from competing ISPs).
>
> The end hosts do not share the same information as the 2 routers
> (the end hosts ignore r
On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan wrote:
> > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
> > autoconfiguration and on-link flags set, and configure /64 prefixes from
> > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
> > as being on-link.
>
On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter wrote:
> But given that route determination is a distributed algorithm, and that
> Homenet devices will not always run the latest and greatest code,
> what action should nodes that are running older code take regarding any
> TLV options that they don't
On Fri, Feb 22, 2013 at 12:04 PM, Michael Thomas wrote:
> I don't see how this requirement is different whether you use NPTv6+ULA or
>> dynamic global addresses. The only difference that I see is that in the
>> case where the machine has a global address, it knows what that address is
>> without
On Fri, Feb 22, 2013 at 10:31 AM, Michael Richardson
wrote:
> I.e. the "0123" is identical for the two prefixes?
>
In the general case where the prefixes assigned by the operators are of
different lengths, it cannot be. Right?
___
homenet mailing list
h
On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas wrote:
> That's why we have ULAs and multiple prefixes.
>>
>
> ULA's are of limited use. I still want to start my washing machine
> regardless of whether I'm at home or not.
And you'll know the current IPv6 address of that washing machine how? If
On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas wrote:
> Sigh.
>>
>
> Sigh all you like, but I share Dave's skepticism that ISP's renumbering my
> prefix willy-nilly and it just sort of works with naming -- including
> addresses squirrelled away in places they ought not be -- is going to work
>
On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht wrote:
> I still find the dynamicism required by renting ipv6 addresses to so
> impact in so many aspects of the "sane usage of stuff like printers", and
> naming, and the security model as to *demand* ipv6 nat in the home...
Sigh.
On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) wrote:
> This is that separate email. As I start, may I make the most direct
> possible apology to my colleagues with other approaches. I'm going to say
> that I think you're "wrong", and say why. That is in the spirit of open
> discussion in whi
On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
wrote:
> Would/could another foot of such a network be on the IETF network?
>
If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
much use.
___
homenet mailing list
homenet@ietf.o
+1 for stuff that works in the real world. "Running code" isn't running
code if it doesn't, well, run. :-)
Mark, Jari, is it possible to revive the autoconfig/source-routing demo
that we had in Atlanta? Even if it's only for a limited time, I think it's
important to show that (or "whether", depend
On Wed, Feb 20, 2013 at 10:58 PM, Ole Troan wrote:
> thinking out loud.
>
> the border router includes in the advertisement of the aggregate prefix:
> - it's own global IPv6 address
> - list of external routes
>
> each internal router:
> - installs (S,D) routes for all of the external routes w
On Mon, Nov 19, 2012 at 5:47 AM, Ted Lemon wrote:
> > That doesn't work in a multihomed situation, though, right? Only if
> there is only one border router?
>
> If there are two border routers, both advertise their prefixes. Hosts
> don't handle this particularly well, as we've discussed elsewh
Most major wireline deployments provide /60, /56 or /48. Examples: free.fr,
KDDI, AT&T. Exceptions are RCS+RDS (working on shorter prefixes) and some
North American cable operators, which AIUI are crippled by sucky CPEs that
fail to do anything useful when they receive more than a /64.
On Thu, Nov
On Thu, Nov 8, 2012 at 12:51 AM, Ralph Droms wrote:
> Using PD in a home network isn't hard. Use a single delegating router;
> most obvious choice is the device that received the prefix from the
> external source.
>
That doesn't work in a multihomed situation, though, right? Only if there
is on
t 2012, at 20:33 , Lorenzo Colitti wrote:
> >> I'm also nervous about both DNS authorisation
> >> and DNS authentication. Who is allowed to make
> >> which DNS advertisements and how do I authenticate
> >> the received DNS advertisement as both valid an
On Fri, Oct 26, 2012 at 5:05 PM, Lorenzo Colitti wrote:
> Using a routing protocol and not using DHCPv6 solves this issue, because a
> router is allowed to deprecate a prefix that has gone away even if it was
> originally announced by someone else, and NUD will let hosts work around
On Fri, Oct 26, 2012 at 4:39 PM, Teco Boot wrote:
> Sure, but you still need to propagate that information to all the homenet
> routers and DHCPv6 servers. In the general case, your host won't be
> adjacent to that DHCPv6 server with this information, or it may be using
> another DHCPv6 server in
On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot wrote:
> Hosts get addresses (DHCP or SLAAC) and then can get the additional info
> with unicasted DHCP for each address, using the MIF extensions. Maybe we
> have to tweak DHCP a little to support this.
>
Just "maybe" ? :)
_
On Thu, Oct 25, 2012 at 11:20 PM, Michael Richardson
wrote:
> LC> Solution: from the border router which discovered the DNS entries
> for
> LC> tvservice.jp, inject those DNS servers into the mesh with a tag
> that they
> LC> only be used for tvservice.jp, and pass that around in the r
On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto wrote:
> a DHCPv6 option to deliver such kind of information, that is, relation
> between DNS domain names and DNS servers, is almost baked.
> https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12
Sure, but you still need to propaga
On Fri, Oct 26, 2012 at 3:24 PM, Teco Boot wrote:
> But seriously: why are you not comfortable with this idea? We need a
> routing protocol for the homenet anyway. A link-state routing protocol can
> carry multiple TLVs, including TLVs for DNS servers. Routing protocols can
> be authenticated. Th
On Fri, Oct 26, 2012 at 2:32 AM, Sander Steffann wrote:
> Yes. The routing protocol saying 'please use this address to resolve
> google.com' might cause some problems... With DNSSEC in place it can
> still cause a denial of service when unsigned or invalidly signed data is
> returned.
>
No more
On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson wrote:
> I'm not comfortable with overloading a routing
> protocol for use as a DNS transport mechanism.
>
Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information
Distribution Protocol" (HIDP). I would expect a useful way to carry HI
On Thu, Oct 25, 2012 at 8:20 AM, Michael Richardson
wrote:
> In the walled garden situation, however, if I had to hide the
> records (which I think is fundamentally broken, but...), then I'd have
> NS delegations from the public DNS into name servers that live in my
> walled garden. So, you
On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson
wrote:
> That solves the routing problem.
> But, what about the naming problem? (whose DNS server do you use?)
>
NPT66 doesn't solve that either, right?
I believe the DNS problem needs to be solved using split DNS at the domain
level, because i
On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas wrote:
> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
>
> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > m...@mtcc.com>> wrote:
>>
>> No, sorry. Corporate VPN's using v6 and the lack of a coherent so
On Tue, Oct 23, 2012 at 5:29 PM, Ray Bellis wrote:
> > I would say that it MUST be deprecated by the arch document.
>
> The arch document is Informational and contains no RFC 2119 keywords.
>
It can't deprecate it, but it can say that NPT66 is not supported in the
homenet architecture.
__
On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas wrote:
> No, sorry. Corporate VPN's using v6 and the lack of a coherent source
> address selection mechanism causes breakage in bizarre and unpredictable
> ways. You are not going to get the results you hope for if your mac uses an
> ISP prefix to g
Since earlier on this thread someone was asking for consensus: for the
record, I agree with all James's points.
I think that homenet should declare that NPT66 is not a supported means for
multihoming in home networks.
Yes, there is a multihoming problem, but no, NPT66 is not a solution/ NPT66
is
On Wed, Aug 1, 2012 at 4:40 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> Excuse front posting, but...
>
> > Today there is no DHCP help in avoiding the "please reboot" messages.
>
> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory?
> They are unicast, which i
On Tue, Mar 6, 2012 at 07:05, Michael Richardson wrote:
>
> In the DNS space, I would like the WG to declare the name-based
> selection of DNS servers (what some want to do for walled gardens)
> should be ruled harmful.
>
> If some walled garden wants the name-> mapping private, then
> just re
On Thu, Dec 1, 2011 at 13:38, Jim Gettys wrote:
> > Because the primitives that are available to you in IPv4 (essentially,
> > NAT and DHCPv4) are different to the primitives available to you in
> > IPv6. IPv6 allows you to do stuff like deprecate your default gateway
> > and prefix, and to have
On Mon, Nov 28, 2011 at 13:35, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> But I'm not sure I really understand the need for it. There's no shortage
> of IPv4 address space in homenets, because they are small and in RFC
> 1918 space. So if you are routing IPv6 in a home net, why not
On Fri, Nov 25, 2011 at 17:43, Mark Townsley wrote:
> Before we decide that we must have an IGP, that it must be
> cryptographically secured, and that we have to tackle key distribution for
> it, I'd like to take a step or two back from the routing protocol part of
> the equation.
>
I'm not sayi
On Fri, Nov 25, 2011 at 01:27, Ted Lemon wrote:
> If one is a member of a homenet and an ISP connection already, and one has
> a blank config, then you might assume that the one with the blank config
> should join the existing homenet. What if they both have a config on them?
> What if you're ac
On Tue, Nov 22, 2011 at 23:54, Ted Lemon wrote:
> Yeah, I don't think either device decides that it is the homenet; rather,
> they are regularly dynamically discovering topology, and deciding what to
> do based on whether they are connected to an edge. Possibly both devices
> are connected to a
It would be cool if I could plug in a new router into my homenet, press a
special button on it and on the router I plug it into, and have the new
router download the homenet config (at least the routing protocol key, but
maybe other things like the wifi SSID) from the existing router.
The button w
On Tue, Nov 15, 2011 at 12:11, Acee Lindem wrote:
> > 3. Can we use normal LSAs to detect collisions? One idea would be "if
>> you see your own router ID in the list of neighbours of a network LSA or
>> router LSA, then there is a collision". Will that work? If so we wouldn't
>> need the hardware
On Tue, Nov 15, 2011 at 11:04, Erik Nordmark wrote:
> On 11/14/11 6:19 PM, Brian E Carpenter wrote:
>
>> Yes, but then we're extending v4 and expecting homenets to run
>> (presumably) RIP.
>>
>
> Why RIP? Same protocol between the home routers as we will pick for
> routing IPv6 in the home.
The
On Tue, Nov 15, 2011 at 09:42, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> If homenet is going to support arbitrary self-configuring topologies,
> and pervasive legacy IPv4 is required, we'd surely end up recommending
> NAT444-within-the-home as the only remotely practicable approach
On Tue, Nov 15, 2011 at 10:25, Acee Lindem wrote:
> > 1. I think the OSPFv3 router ID should not be based on the MAC address
> because that will encourage people to assume it's unique "most of the
> time". I think we should just make it a pseudo-random number so it's clear
> that uniqueness is on
Apologies if ther's already a public comment thread on this; I couldn't
find it. Please feel free to hand me a cluepon.
1. I think the OSPFv3 router ID should not be based on the MAC address
because that will encourage people to assume it's unique "most of the
time". I think we should just make it
On Tue, Oct 25, 2011 at 11:34, james woodyatt wrote:
> Yes, I realize that means that application content providers with big
> global data centers won't be able to directly address every little sensor
> device in every home network on the planet
>
Actually, that's not what it means. It means tha
On Tue, Oct 25, 2011 at 11:07, james woodyatt wrote:
> Sure, that optimizes routing, but it forces applications to be more
> complex. Do you really want all the STUN / TURN / ICE code that we have
> today to keep being necessary?
>
>
> That's all going to be necessary anyway because of the ubiqu
On Tue, Oct 25, 2011 at 11:00, james woodyatt wrote:
> Admit defeat and either bridge everything or route longer-than-/64
> prefixes. I hope it won't come to that.
>
>
> I would prefer to deploy NAPT66 rather than route prefixes longer than /64.
> In fact, I'm tempted to to say we should prefer
On Tue, Oct 25, 2011 at 10:47, james woodyatt wrote:
> 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
>
On Mon, Oct 24, 2011 at 22:12, Hemant Singh (shemant) wrote:
> >If you haven't read the homenet email conversations, how do you know that
> these are regressions?
>
> **
>
> ** **
>
> Some regressions are fairly clear from just glancing at the subject of
> emails in homenet. The example is ND Pro
On Fri, Oct 21, 2011 at 17:18, Hemant Singh (shemant) wrote:
> I don’t have the time to read the copious emails of homenet, but seeing
> some emails here and there I see homenet regressing on issues that are
> closed in the v6ops IPv6 CE router document development.
>
If you haven't read the home
On Thu, Oct 20, 2011 at 21:59, Ole Troan wrote:
> but seriously, just remove it from the build.
>
Yep. Overlay networks will never match native performance. Please don't do
6to4, please implement RFC 6204 instead.
___
homenet mailing list
homenet@ietf.
On Wed, Oct 19, 2011 at 22:34, Jim Gettys wrote:
> On 10/19/2011 03:43 AM, Ole Troan wrote:
> > you aren't helping things work better by doing 6to4.
> > please disabled by default, if you absolutely want to support it at all,
> hide it somewhere under the Wizard menus.
>
+1. Please read Geoff Hu
On Sun, Oct 16, 2011 at 16:47, David Täht wrote:
> Just as a data point, the babel and AHCP protocols creates a router-id
> from a EUI-64. problem solved, there.
And when there is a collision, what happens? The network breaks?
Note that I say "when" there is a collision and not "if" because:
On Wed, Oct 12, 2011 at 05:33, Ted Lemon wrote:
> The second reason is that electrical systems are essentially topology-free.
> Any point on the system is essentially equivalent to any other. This is
> not true of a home network with routing. What we are talking about is
> essentially the p
On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar wrote:
> Random number selection for router-id and this sort of recovery would
> solve the zero config OSPF issue related to router-id selection.
>
> Not yet solved in existing zospf draft (afaik) but solvable.
zOSPF says what do do in the case o
On Fri, Oct 7, 2011 at 16:18, Erik Nordmark wrote:
> Today there are IPv4 NATting RGs, and there are cases when you end up with
>> multiple (could be tied to separate services or other functionality) in a
>> home.
>>
> Seems like we'd like to be able to introduce IPv6 support without NATs into
>
On Fri, Oct 7, 2011 at 14:25, Erik Nordmark wrote:
> The slides say:
> "Support arbitrary topologies including loops"
>
> What is the implication of that on IPv4?
> Are you assuming that the dual-stack home network will delegate IPv4
> prefixes and route IPv4, with no internal NATs?
>
> How would
On Mon, Oct 3, 2011 at 08:58, Randy Turner wrote:
> I would hope that we would NOT be seriously considering OSPF or IS-IS in
> the home...this seems like using a sledgehammer to kill an ant.
>
If the devices we're talking about have enough resources to run them, and
they have desirable properties
On Mon, Oct 3, 2011 at 08:33, Qiong wrote:
> Agree. I think the HOMENET requirements should be derived from major
> devices in the home network scenario. Maybe currently we should firstly
> focus on multiple router scenario for traditional fixed and wireless network
> for multiple services (espec
82 matches
Mail list logo
