Is this the same as a hidden primary name server?
Cheers
Ole
> On 5 May 2021, at 21:09, Michael Richardson wrote:
>
>
> Ted Lemon wrote:
>>> On May 5, 2021, at 11:51 AM, Michael Richardson
>>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another
Hi Ted,
>> Are you saying there might be gaps in HNCP? Or things we could do to make it
>> more deployable?
>> If it's just a matter of running code missing, I'm not sure defining
>> anything else new in the IETF would help that problem.
>
> There are definitely missing features from the protoc
Homenet has solved the problem of self-configuring networks in arbitrary
topologies.
>>>
>>> If that were true, I wouldn’t be asking this question. We’re still
>>> chugging along, but we don’t have something that nay router vender could
>>> even consider shipping right now. There isn
Ted,
>> Homenet has solved the problem of self-configuring networks in arbitrary
>> topologies.
>
> If that were true, I wouldn’t be asking this question. We’re still chugging
> along, but we don’t have something that nay router vender could even consider
> shipping right now. There isn’t en
Mikael,
>> RFC7084 does not have any support for internal routers.
>
> While this is true, OpenWrt does support DHCPv6-PD within the home, out of
> the box. I also have a report of AVN Fritzbox supporting sub-PD without
> additional configuration.
>
> In all devices I've looked at the WAN is W
Ted,
[top posting]
RFC7084 does not have any support for internal routers.
Futher:
It might just be the way you describe the use cases, there seems to be a
misconception about how routers work with regards to ND “advertisements”. ND is
not a routing protocol.
Hierarchical PD which you also
> "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
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
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
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
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
> I am interested to learn what people think about whether equal-cost
> multi-path routes are needed in homenet. Given the previous discussion about
> parallel wireless links - which I know I have in my house and can't use -
> I've been wondering if these have been considered.
>
> ECMP is crit
> 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
Juliusz,
> I'm wondering if there isn't some interaction between Redirect messages and
> source-specific routing that we're overlooking. RFC 4861 Section 8.3 says
> the following:
>
> Redirect messages apply to all flows that are being sent to a given
> destination. That is, upon receipt
Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.
Document: draft-ietf-homenet-dncp-07.txt
Reviewer: Ole Troan
Review Date: July 7 16, 2015
The document now reads much better. I do get the impression that the text is
reverse engineered from code
Brian,
>>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>>> hosts to
>>> be updated to be effective.
>>
>> IPv6 multi-prefix multi-homing requires both hosts to support it. which
>> means transport fixes.
>
> Or fully operational shim6, which was conceived and designed
>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>> hosts to
>> be updated to be effective.
>
> IPv6 multi-prefix multi-homing requires both hosts to support it. which means
> transport fixes.
to reply to myself. is anyone aware of any document describing the
"expectati
> Much as I love MPTCP, it only helps TCP sessions. And it requires both
> hosts to
> be updated to be effective.
IPv6 multi-prefix multi-homing requires both hosts to support it. which means
transport fixes.
cheers,
Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Liang,
what do you mean by "multiple services"?
if you mean walled garden, the homenet architecture only has the following to
say:
"It should be noted that some multihoming scenarios may see one
upstream being a "walled garden" and thus only appropriate for
connectivity to the services
> Following question may strictly speaking be out of scope for Homenet, as it
> is about the WAN side interface and interaction with the upstream ISP router.
>
> Whilst setting up my own HNCP testbed, I was attempting to configure my own
> "last-hop ISP router" assuming a customer-owned Homenet
>>> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek
>>> wrote:
>>>
> The client is running a stub implementation of the routing protocol.
>>>
I thought we already had decided we didn't require changes to the host?
>>>
>>> We don't *require* changes to the host. We propose optional host
> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek
> wrote:
>
>>> The client is running a stub implementation of the routing protocol.
>
>> I thought we already had decided we didn't require changes to the host?
>
> We don't *require* changes to the host. We propose optional host
> modification
Mikael,
>> Back to the subject: What are the requirements of a high performance WiFi
>> home network to the homenet routing protocol? I guess we don't know.
>
> Within the current framework to solve this problem with what exists today
> when it comes to clients, I would say we need either:
>
>
>>
It means that every single device on a wired network is on a different
subnet. Perhaps it doesn't cause any extreme harm, but it certainly makes
managing and debugging the network harder, and it means that you can't
have a layer two switch anymore. So the question I wou
>> It means that every single device on a wired network is on a different
>> subnet. Perhaps it doesn't cause any extreme harm, but it certainly makes
>> managing and debugging the network harder, and it means that you can't have
>> a layer two switch anymore. So the question I would ask is no
>> PVD tell you also about the kind of connectivity available there etc. While
>> I am sure we _could_ fabricate local one, it is much easier to tell that
>> e.g. one upstream connection is pay-per-byte 4g, and other one is VDSL2 and
>> let hosts make educated choices instead of guesses about so
Markus,
>> All routers gather this information through HNCP and use it to configure
>> hosts. DHCP options that are associated with a given delegated prefix are
>> given to hosts associated with the link prefix provided by the prefix
>> assignment algorithm. DHCP options that are not associated
Michael,
>> 1) pure peering - homenet -> LLN ::/0
>> - LLN -> homenet more specifics
>> for LLN routes and cloud service prefixes
>
> I don't understand your ::/0 here.
> I think the LLN gets a ::/0 route into the homenet, and the homenet gets a
> specific route into the LLN. Is this what you
Juliusz,
you could also inject the route with a 3rd party next-hop pointing to L.
cheers,
Ole
> On 16 Nov 2014, at 10:54 , Juliusz Chroboczek
> wrote:
>
>>> If the latter, I can see some opportunities for transient routing loops
>>> if not done carefully. (And you certainly don't want a rou
Pierre,
>> while 2 and 3 require participation in HNCP, my worry is that even HNCP is
>> too chatty for the LLN to deal with. do we have any numbers? presumably one
>> could design a stub HNCP, where the peer only received messages relevant to
>> it, possibly even with a HNCP sleep proxy.
>
>
>> While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
>> proposed that the IoT device domain would never be used for transit so it
>> only needed to get a default (or other aggregate) and inject a prefix and
>> the HNCP could be made to satisfy this requirement.
>
> Could you
Ted,
>> the "flow-through" model as far as I can recall suffers from DHCP's general
>> problem of dealing with multiple sources of information (think multihoming
>> with separate CE routers), in addition you either need to build what's
>> essentially a spanning tree of DHCP relays or you need s
>> What does flow-through PD mean? Do you have any reference on that?
>
> It means that the edge router has the delegation, and then sub-delegates
> individual /64s from the pool of /64s it was delegated by the ISP, rather
> than splitting its delegation and delegating chunks of that delegation
David,
> ::/0 from 2001:db8:1::/48 via PA-provider-1
> ::/0 from 2001:db8:2::/48 via PA-provider-2
> ::/0 from 2001:db8:::/48 unreachable
> 2001:db8:::/48 from 2001:db8:::/48 via IPsec-gateway
> 2001:db8:::/48 from ::/0 unreachable
>
> Where the last route would prevent accidental
Fred,
>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1
>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1
>
> Speaking strictly for myself, I’m not sure why homenet is relevant. The
> technology is related
Pierre,
I certainly understand your argument, and we don't disagree on the technical
merit.
> I’m proposing this change then.
>
> 1. In case the provided prefix is 64, the default consist in assigning
> prefixes of length 64 first.
> 2. I’m adding a reference to 6man-why64.
>
> When the algor
Pierre, Alex,
please make sure this document does comply with
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
while I think the algorithm and data formats should support any prefix lengths,
I don't think the sections dealing with "what if we've run out of prefixes"
should be included in
>>> It seems to me that you are grasping for a use case to justify a split
>>> where none is needed. Protocols like OSPF, IS-IS and Babel would all
>>> work in both environments. RIP won't. So this seems more like an
>>> argument not to use RIP than an argument to have two different homenet
>>> r
> At IETF 89 in London we took three hums:
>
> 1. On use of OSPF vs HNCP for configuration - strong consensus for HNCP
>
> 2. On how many routing protocols we should support in Homenet -
> strong consensus that it should be zero or one, but no consensus yet
> on which.
>
> 3. On adoption of HN
Ted,
>> you make it sound like that's a part and parcel of DHCP. I can't see how you
>> can implement that today.
>
> Eh? It's dead trivial. The draft already sets up relay agents—the only
> difference is that all relays now relay to both CERs, not just one. The
> requesting routers get
Ted,
>> please take a look at those drafts, and let us know what we've missed in the
>> DHCP PD "solution space".
>
> I've read all those drafts at one time or another. I just checked the
> latest version of
> http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it appears
> to
Ted,
>> actually, we're talking about prefix assignment. which may be splitting
>> hairs, but isn't quite the same as prefix delegation.
>
> Splain? You mean we're talking about the general problem, rather than the
> DHCP-PD solution? If so, that's fine, but the specific comment that Markus
Ted,
>> I thought you were asking for host changes to support multiple servers (even
>> if RFC says they should, and I’m not sure it does, I have yet to find one
>> that does).
>
> I think host changes to make this work will be crucial to having hosts that
> can operate on multiple prefixes ma
>> Given N*10^8+ (conservative estimate, N some single digit probably)
>> potential homenet hosts already out there and 0 homenet routers, designing
>> with the assumption that ‘yeah, hosts can change’ doesn’t sound too
>> reasonable to me.
>>
>> Then again, what’s wrong with fighting windmills
> 7) I generally despair of this entire debate, and wish more people
> were writing code, doing experiments, and working inside the real
> world. I hate that this discussion has ratholed on the method of
> distribution, rather on than on "what configuration information needs
> to be propagated insi
>> You (and others) who speak of a "Homenet Configuration
>> Protocol" seem to be making an assumption which is far from
>> clear to me. That assumption is that config parameters in a homenet
>> will come in some sense top-down from a higher level source of
>> authority.
>
> No, I don't think that
Teco,
>>> My opinion: put the prefix distribution protocol on top of NDP, so all
>>> nodes are informed.
>>
>> what are the arguments for involving hosts in the prefix assignment protocol?
>> as opposed the existing router to hosts protocols (ND/DHCP).
>>
>
> With multiple prefixes, hosts have
Teco,
>>> There is something common on prefix distribution in Homenet, small
>>> office/home office networks, branch office networks, ad hoc networks and
>>> even in enterprise / campus networks. The prefix distribution protocol
>>> could be a single protocol. We better not try to converge to a
>>> I can see reasons for having shared sub-layer for routing protocol and
>>> prefix distribution protocol. As example, in MANET we have such already:
>>> RFC 5444 and 5498. If we define a set of TLVs for border router information
>>> and prefix distribution, it can run on whatever routing prot
Mikael,
> So to continue this, even carrying service discovery information leads to new
> information flow in that the routing protocol now needs to update a service
> discovery "Information Base". At least this is less intrusive than having it
> set interface IP addresses.
there is another ch
Teco,
> I can see reasons for having shared sub-layer for routing protocol and prefix
> distribution protocol. As example, in MANET we have such already: RFC 5444
> and 5498. If we define a set of TLVs for border router information and prefix
> distribution, it can run on whatever routing proto
Brian,
>> requirements from homenet-arch (I might have missed some):
>> - must support multi-homing
>> - each link should be assigned a stable prefix
>> - efficient allocation of prefixes
>> - should support both IPv4 and IPv6
>
> I think you need to add
> - must allow source-address-based next h
Dave,
> 1) in the multi-homing case you want requests from a local dns server
> to be sourced
>from the right network to the right ISP-provided forwarder. (think
> I have a fix for
>that but it involves abandoning resolv.conf for specific dnsmasq
> configuration.
I can't quite see how you
border" HGWs (when do you send
> out DHCPv6?)...
>
> Any thoughts?
>
> Branimir
>
>
>
> On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson wrote:
> On Thu, 30 Jan 2014, Ole Troan wrote:
>
> We need to decide, if we want prefix assignment and distribu
t; Le 30 janv. 2014 à 13:38, Alexandru Petrescu
>> a écrit :
>>
>>> Le 30/01/2014 13:28, Ole Troan a écrit :
>>>>>>> Could it be separate (existing) protocol?
>>>>>>
>>>>>> if one had existed, sure. requirements from
>>> Could it be separate (existing) protocol?
>>
>> if one had existed, sure.
>> requirements from homenet-arch (I might have missed some):
>> - must support multi-homing
>> - each link should be assigned a stable prefix
>> - efficient allocation of prefixes
>> - should support both IPv4 and I
Alex,
>>> In my understanding, there is a need to couple the prefix assignment to the
>>> routing protocol. Although I am not sure how much tight, or what tight and
>>> loose might mean.
>>
>> to clarify what I meant:
>> tight coupling --- integrated in a routing protocol, e.g. in
>> draft-a
> In my understanding, there is a need to couple the prefix assignment to the
> routing protocol. Although I am not sure how much tight, or what tight and
> loose might mean.
to clarify what I meant:
tight coupling --- integrated in a routing protocol, e.g. in
draft-arkko-homenet-prefix-assig
Steven,
>>> We have switched to RA-Handling in userspace for similar reasons
>> already so I guess it's only the next logical step to create separate
>> routing tables for each upstream interface to do source-based routing
>> and filter out ULA-traffic on this layer instead of through iptables.
>>
[...]
> We have switched to RA-Handling in userspace for similar reasons already so I
> guess it's only the next logical step to create separate routing tables for
> each upstream interface to do source-based routing and filter out ULA-traffic
> on this layer instead of through iptables.
don't
[...]
> We have switched to RA-Handling in userspace for similar reasons already so I
> guess it's only the next logical step to create separate routing tables for
> each upstream interface to do source-based routing and filter out ULA-traffic
> on this layer instead of through iptables.
don't
Juliusz,
there is also a draft: http://tools.ietf.org/html/draft-troan-homenet-sadr-00
an implementation using Linux table support will require duplication of route
entries into multiple tables.
cheers,
Ole
On May 7, 2013, at 14:03 , Juliusz Chroboczek
wrote:
>>> If you're actually doing s
Teco,
[...]
>> I don't think the homenet should get into the "policy" part of this, but
>> rather just provide some simple tools/infrastructure.
>
> Hmm.
> I also prefer simple tools/infrastructure. But let's try to solve some
> problems, or at least we shall not block solving later on.
are t
Teco,
> Still I am puzzled how we can support multiple provisioning domains with
> multi-addressed hosts in a homenet. May I reference to the discussion in mif?
> http://www.ietf.org/proceedings/86/slides/slides-86-mif-1.pdf
>
> For providing information on provisioning domains, we might look i
>> There is no real reasons for ISP's to only do /64s except spite the
>> customer. The difference in costs from the RIRs for the bigger
>> address space is chump change even for developing states. All their
>> equipment will support > /64 because the big players want to support
>> that.
>>
> Ac
Teco,
>>> Reading the homenet-arch, I can't find how multi-addressed hosts are guided
>>> to prefer one address over another. I think such facility is beneficial in
>>> multi-homed homenets.
>>
>> the intention is to propagate the SAS/DAS policy given with
>> draft-ietf-6man-addr-select-opt,
>
Teco,
> Reading the homenet-arch, I can't find how multi-addressed hosts are guided
> to prefer one address over another. I think such facility is beneficial in
> multi-homed homenets.
the intention is to propagate the SAS/DAS policy given with
draft-ietf-6man-addr-select-opt,
and more specifi
>> From the quoted draft: "for the purposes of this document, assume that
> each link has its own unique Unicast DNS domain name",
> which I don't think is acceptable in Homenet. I don't want my phone's
> name to change when I walk out to the shed.
in a service discovery world, would you even car
> My understanding was that they were going to extend mDNS to work on
> multiple segments, rather than gluing mDNS "islands" with DNS... but I
> have not really followed the discussions in the mdnsext.
see:
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01
cheers,
Ole
_
>> Stupid question:
>> Can we enforce requirements on host implementations as a result of
>> homenet?
>
> We should avoid it wherever possible.
for service discovery that's pretty much unavoidable.
cheers,
Ole
___
homenet mailing list
homenet@ietf.org
>> Ok. I see it in the charter. I dont find it particularly appealing or worth
>> a great trade off for the level of complexity involved. Especially if the
>> tradeoffs require nat66 or something similarly complex
>
> Touché.
>
> Seriously, though, the point of routing in the home is that you r
Ray,
[...]
>>2. Aren't we forgetting the first hop?
>>
>>Given a shared subnet/prefix/link with 2 CPE routers performing some
>>fancy new form of forwarding (based on PBR or SADR or whatever)
>>that is
>>also shared by existing host implementations, how will the routers
>>
Fred,
> Ole Troan and Lorenzo Colitti documented their model, which is strictly
> egress routing based on the OSPF AS-prefix-LSA and the assumption of
> automated prefix allocation. This is not multi-topology; it in effect tags
> the default route advertised as a route from
Ray,
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 with the border's
global as next-hop.
normal unicast routing
Ray,
> I have read this draft and find it useful.
>
>> A routing entry may have both (S, D) paths and (*, D) paths. The
> longest match wins
>
> Section 5 seems to suggest SADR is just a tie breaker applied to the
> subset of equal length D routes, but I think you probably should be more
> spe
David,
thanks for the thorough comments.
> nice to see this moving forward! Comments below with section
> copy/paste.
>
> On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote:
>>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
> [...]
>
ange-Organization-Authas: Internal
> X-Ms-Exchange-Organization-Authmechanism: 10
> Mime-Version: 1.0
>
>
> A new version of I-D, draft-troan-homenet-sadr-00.txt
> has been successfully submitted by Ole Troan and posted to the
> IETF repository.
>
> Filename: draft-troan-home
Mikael,
Given that we want multiprefix multihoming with multiple prefixes, SADR is
pretty much the only solution.
But consesus? Wouldn't dear getting anywhere close to that. :-)
Cheers,
Ole
On 15 Nov 2012, at 16:15, "Mikael Abrahamsson" wrote:
> On Thu, 15 Nov 2012, Ole Trøan wrote:
>
>>>
On 7 Nov 2012, at 14:50, "Teco Boot" wrote:
> This should be in the homenet-arch, I think.
>
> It sounds so obvious to me, that I described this in a short text in BRDP:
> A Router should request a prefix for attached subnetworks, with
> DHCP-PD [RFC3633], where there is at that moment no
> Can you provided a precise definition of "walled garden", as well as, define
> the bi-directional connectivity rules with a few bullets (hopefully less than
> 5).
> I fear there may be more than one view of this (or possibly I'm the only one
> ;^).
I presume we are talking about multi-homin
Michael,
> Is there some reason that the flooding mechanism can't distribute the
> list of edge CPE routers, and then DHCPv6 can be used in unicast
> request/reply to ask those CPE routers for things.
>
> (I would even wonder if the CPE routers shouldn't be identified by their
> ULA rather than s
iple DHCP servers. If we do
>> it another way, whether ZOSPF's or some other way, we have the same problem
>> in the sense that there will be multiple sources of subnet prefixes.
>>
>> On Nov 16, 2011, at 2:56 PM, Ted Lemon wrote:
>>
>>
>>
&
Ted,
>> If we do it another way, whether ZOSPF's or some other way, we have the same
>> problem in the sense that there will be multiple sources of subnet prefixes.
>
> Yes. This becomes an even uglier problem as you progress into the network,
> because while at the edge you can tell that you
Fred,
We need to be aware that not every network may be able to reach the
Internet... So you might need to have an address from every available
DHCP server, not just the "best," one, or even a "random," one.
>>>
>>> Yes, this is part of a problem space of which I have become keenly
>> do we need to?
>> in a self organizing unmanaged home; if we were to do a combination of a
>> network wide flooding mechanism and RAs. would we need DHCP in the network
>> at all?
>
> I am not claiming that we do. However, the problem exists whether we do DHCP
> in homenet or not.
yes, ind
>> We need to be aware that not every network may be able to reach the
>> Internet... So you might need to have an address from every available
>> DHCP server, not just the "best," one, or even a "random," one.
>
> Yes, this is part of a problem space of which I have become keenly aware over
> th
Ted,
>> The mic line was too long to bring this up:
>> You suggest using RFC 3633. How about RFC 2894 (Router renumbering) too?
>> Typo: the draft actually cites RFC 3363, which is not what you intended...
>
> Ditto on the mic line—very frustrating. I think you overestimate the
> obstacles to
Howard,
> I've said that I don't think we need a full dynamic routing protocol. There
> are other options for discovering an available path. To stimulate creative
> thinking, I've written a draft proposing one alternative that should be light
> to implement in home gateways:
> http://www.asg
>> but seriously, just remove it from the build.
>>
> This I disagree with; 6to4 is seriously useful in certain environments
> (like mine). Having it present can be useful, having it on by default,
> is problematic. Unless/until we can fully automate something else I want
> it available.
yes, I'
Jim,
> Yes, his data was taken just before/as Comcast put its relays into
> production; it's not what we see on that network. Before then, almost
> all traffic went through some poor server in Wisconsin, as I remember.
> It sucked.
>
> There is a self fulfilling prophesy here: if no one has dec
> However, overall trends on this list are discouraging.
>
> 1) Getting IPv6 working well inside the home is a hard problem! It helps
> to actually try to make something work, to see the relevant details. I'd
> like it very much if at an upcomin
>
> I've built 3 such networks, and am in the proce
Ted,
>> using the electricity network as an analogy, can we make a distinction
>> between "safety" and "security"?
>> the electricity network in the home is somewhat self protecting with
>> breakers and earthing.
>> a home network must protect 'itself', i.e. handle any device plugged into
>> it
> I've been reading the list with interest and have a question.
>
> When various devices in the home figure out which does what,
> and do that periodically to handle changes, there's clearly
> the potential that a zombied host tries to try take over
> stuff with undesirable consequences.
>
> My q
Erik,
btw, "border discovery" needs to be done regardless of topology or prefix
assignment solution choice.
on a border you (may) want firewall on, you want a ULA border, you want a
organisational or site multicast border...
cheers,
Ole
___
homenet ma
Erik,
>> If all the ports are the same, no designated uplink, that is better.
>
> While I can see that we can build the internals of the home network with
> devices without a designated uplink (automatically configure prefixes, the
> routing protocol etc), what I don't understand is how the con
Erik,
>> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't
>> really been described anywhere) as a method for numbering a routed home.
>> please let me be clear that I'm not convinced this is a good idea. i.e. why
>> not just get< /64?
>> I do think we could get somethi
//tools.ietf.org/html/rfc5889
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd
> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>
> cheers,
>
> Pascal
>
>
> -Original Message-----
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@i
1 - 100 of 109 matches
Mail list logo
