IETF 84 - Homenet Working Group - 31st July 2012 Chairpersons: Mark Townsley & Ray Bellis Scribes: Jiazi Yi & Thomas Clausen ================================================== 15:20 - 15:30 Note Well, Jabber Relay, Note taker(s), Agenda Bash 15:30 - 15:45 Homenet Architecture Update draft-ietf-homenet-arch-04 (Tim Chown - 15m) --------------------------------------------------------------------------- There has been 2 revision since last IETF, main change is the structural changes so as to groups related principles into sections (e.g., all policy based stuff together), to remove duplication and removing the numbering of the principles. The new version doesn't emphasise requirement too much. Also, there was some added text on naming and service discovery Would like feedback of the latest version of the text, are there any gaps to consider? Believe the text is relatively mature - the open question is if the WG thinks that this document is ready to progress? -- subject to, of course, the naming/service discovery discussion happening today? Mark Townsley (MT): Poll for how many have read it? (Many) Is this mature (some) Are we OK to remove bullet points? Michael Richardson (MR): Worried seeing many forward references to upcoming solutions. This will never get published in this state, will these be removed, or updated, or... There are a dozen or so references to I-Ds that may never get published, they should at best be informative, but we mnay perhaps want to look at this differently. Mark: so it's more procedure problem. Tim Chown (TC): We just put this into the first version, as examples. It's a fair question. I don't have strong opinion either way. MT: Certainly a -05 is to come out capturing the naming/service discovery of today, but I am imagining a WGLC before the next IETF Kerry Lynn (KL): I do not know if I am the only one feeling this way, but I would think it was better if it read a bit requirements-based. For each of the areas, we should have a list of things that we all agree should be solved. Second, I didn't see any reference to multicast forwarding. Is it out of scope, or we are not there yet? TC: The document is, at times, a bit chatty, I agree. MT: That intersects pretty significantly with the naming/services discovery Hopefully we can touch some of the issues you raise today. Would like to avoid bullet points. We could work on a less chatty version of the document. I hear that it is not fully baked yet, 15:45 - 16:50 Naming and Service Discovery - what's the diff? (Stuart - 20m) --------------------------------------------------------------------------- Stuart Cheshire (SC): Naming vs service discovery : The are largely the same thing. o Naming - single answer. o Service discovery - zero or multiple answers. In multihomes environments, when resolving a name one might get multiple records, so they are not even that different. Host name really naming logical services. already a lot overlap there. Naming comes in many guises. DNS ==> ARP/IPv6 ND ... in hierarchy. Multicast rsolution v.s. Centralized Repository Multicast is zero configuration environments is no very efficient, but is robust. Repository, in homenet, sometimes acceptable. Routers with subnet, and there is a place to put the repository. 15 years ago, the debate of DHCP for home user - assertments that nobody at home would run a DHCP server, that belonged in a big 19" rack in the datacenter - now, look at all the boxes doing DHCP. By that token, having an DNS server in a gateway might make sense. Local v.s. Global names. With local networks, this can be zero-config. .local for names on the local link. Can use meaningful names. global names needs meaningful names, but user-involvement needed - this is an operational reality that we can't get rid of -- it can never be totally zero configuration. conclusion: there is a 90% overlap between naming and service discovery. should take advantage of it. Ray Bellis (RB): Please keep the discussion focused Lee Howard (LH): The difference is in the solution space, in which you can solve a lot of the service discovery problem set, in the same way with the naming problem set. However, the problem set is a bit different. For example, naming a host. Disagree with that the problem set is the same. Also, didn't talk about the advertising v.s. query, which is different case. Broadcast/multicast, every one has to wake up and listen to it. SC: I think the diff is smaller than you think; dynamic addressing - if/when a host gets an address, it needs to be recorded somewhere. Same with service Ralph Droms (RD): Was going to make the same point. The binding between identifies, and how that binding is recorded, can be and should be separated. Often, some information is broadcast resolved, cached and accessed in a repository, even in different forms at different points of time. Would be helpful to tease them apart. Anders Brandt (AB): I know I am stating the obvious here, but The market has chosen somewhat, we have this on our mediaplayers, nat boxes etc., they all find each other - it is already running, regardless of what addresses they have otherwise David Oran (DO): Need to separate service model for service discovery. Because of power management and a whole bunch of reasons, things what to delegate, for service discovery, you can bundle ... I think you can unify a bunch of things by keeping the service discovery model and viewing the repository model as simply machine that you can delegate. LH: The benefit of these solutions is, that the address is opaque - the names (service names) abstract over the address. As long as you can reach it (the service name), the actual address is m2m stuff. Kerry Lynn (KL): Base capability that's built in: mDNS etc., is already widely deployed. If we can use that existing capability to e,g. see values in a proxy, that would be useful. There has also been some discussion on the list where a name appears multiple places, e.g. in a local and a global registry. How to make bindings between bindings? MT: Can you answer that? (looking at SC) SC: This is not fully explored. A simple way is take the first bit of the name, have something different in the end. e.g. **.local, ***.myhome.... not much experience, might find problems if try. AB: A convenient feature that client doesn't make assumption on the address used last time for certain services. I have been asking for ULA's for a long time... we can talk later. SC: We live in a world of dynamic addresses today. RD: One of the things that you mentioned was about local-vs-global namespaces. Some care is neeeded, least you end up with two namespaces, one for local and one for global resolution. There are times where you do want to do name resolution "relative to where you are now", and other times where you want to do name resolution "relative to the whole internet". An user-friendly way needs to exist to swap between the two. The current specification force the separation. Toerless Eckert (TE): I have a simple question: If I do a ssh to medial server to login, normally DNS do a record look up for the IP address. I can already do that today or I should unified scheme basically use MDNS to find that record? SC: If you look for a media server at .local. Today in an ipad, it will be a local multicast DNS lookup for that name. Aways from homenet access, .local won't succeed. make a alias? Don't have that mechanism at the moment in the protocol. RD: One thing to keep in mind, the name resolution, the home network will never see the hostnames, services name we talking about directly. Will talk to another layer of name resolution, user interface. Andrew Sulivan (AS): You were saying, to follow up on the same topic, you were saying that you have two namespaces that are not the same, and we can just give them the same first bits and different suffixes. SC: I think it is pretty easy to keep them in sync ..... AS: That was what I was afraid that you would be saying, please do not say that, it's wrong, we have a lot of experience showing that it is hard/impossible to do RD: I promise that this would be the last time. Want to channel Ted Lemon One thing to keep in mind about the name resolution mechanism is, that for many users, they will never see hostnames or service names etc. directly, but will talk with another level of name resolution -- the user interface -- that will pop up another world of names and concepts in a menu or something. We need to keep this in mind also. SC: Good point, we cant discuss any of this until we figure out what the user experience will be. If we build technology without knowing what use it is, it'll never be good. ??? (didn't articulate name in audible fashion): There is a difference between when you're having "humans speaking to each other, using names" and machines. AB: No user will want to to wait for a printer to turn up itself, it is expected to be instantaneous. SC: In the past, CUPS would work like a wifi access point, come on and beacon all the time. AB: The point is that this depends on if it's machine to machine or machine to human, I disagree. As long as we have local names and they're unique, no reason that they not be humanly readable? What makes a human readable name bad for machine-to-machine Michael Thomas via jabber (MT): If you posit a global name as a cname for a .local name, why use the .local at all? SC: Good question, don't have full answers on that yet. We need more experimentation. Dave Thaler (DT): This Triggered something that I thought useful to bring up. The context to this was to give people a way to understand name/service discovery. A second issue: people mean an additional thing beyond that in the IETF: name resolution is mapping layer-7 to layer-3 addresses. Whereas service discovery is lauer-7 to layer-4 (IP-PORT). - Proposed Naming Solutions (Daniel Migault - 15m) --------------------------------------------------------------------------- draft-mglt-homenet-naming-delegation-00 Introduction; home network, what end users want... user prefer to used names. need to setup a naming architecture... want automatic configuration, also consider advance config, or manual config. privacy ISP wants it be scalable. Naming delegation architecture. the key aspects is to configure it beween the CPE and the others. Setting naming delegation, and DHCP Exchanges draft-mglt-front-end-naming-delegation-00 IPV6 home network front end delegation architecture. not opposing the previous, but for other goals. CPE is not designed to handle heavy load. The idea is that the ISP can provide a front server to protect the CPE. No DNS queries are addressed to CPE. Front end is gathering the repsons. DNS protocol is used. The CPE has to be configured a little different from the previous architecture LH: Talking about both drafts: no. We don't why to be involved in the DNS for our customers. We do not want to offer our DNS servers as DOS point MT: When having a managed cpe that is provided by ISP, and tightly coupled to the ISP, maybe the view can be different. Are we solving the problem, or we are just talking about the retailed cpe? SC: I want to be less negative. There's some value here It is more appropriate to take this the DHCP wg, it is not a homenet problem. Already existing dyndns, back-to-my-mac etc. supporting such stuff. Some users may want to get a DNS name from their ISP, and so that will change when they change ISP - whereas others may not. The value I see is the autoconfiguration: how do I autoconfigure a nameserver over DHCP (if I get a static name from my ISP) Eric Kline (EK): What do you imagine the method for updating is? Zonepulse? If the frontend is going to fwd every query to the CPE, the CPE will be DOSable still. Daniel Migault (DM): DNS (std) Chris Griffith (CG): Looking at the design, I am still trying to get my head arounbd this: you delegate to the CPE .... ????: The ISP is offering std. DNS server. Works regardless if the CPE is up or down. CG: Are we assuming that the ISP is hosting the authoritative master? You can run an authoritative server at the CPE and not rely on the ISP-hosted autheritative master constantly delegate. DM: We do not want the ISP to host all the namespace for inside the homenet TE: What happens if my internet connection fails? If so, can I still do resolutiuon of my in-home names? It seems that there's only one dns server, outside of my home. Peter Koch (PK): I find this paparazi activity disturbing and annoying. I find the solution attractive, but I cannot see what you solve with solution-2 on your slides. It opens up a tight lock-in to the ISP's namespace/structure. So, in summary, 1. sophisticated solution, but I do not appreciate the problem you are trying to slove. 2. knock in the the ISP name space, really don't want to engage into. recommend that wg doesn't do that. AS: Disclaimer: I work for dyn.com It seems to me that what you are doing is something we've already solve - we've got customers, they do this. If you want to do something tightly linked to your service, rather than link to DHCP, why do you not invent a discovery mechanism once up, then use existing protocols Michael Thomas (MichT) The big problem here is the implicit tight coupling between the ISP and the CPE by using DHCP. What if I want to want to use another service where DHCP isn't an option, like say google. If this is decoupled from DHCP, it would be a lot more reasonable - Name Service Design Principles - Shooting for consensus (Tim - 30m) --------------------------------------------------------------------------- Name service design. archit. drat is relatively firm. Fundamentals... Name space... DT: There may be a slight variation on the bottom bullet (running [protocols/code) We had at last meeting a discussion, there could be v1 and v2 scenarios. Can it work with existing hosts, or not? That's fairly fundamental and v1 I think that I want to go along with the point that stuart was making: if you have a global name, don't ever use the local one. Always use/bookmark a global name if known. What do users bookmark/use? - whatever thjey can get. What we want them to get is a global one, if at all possible, but local is and should be last-resort. Robby Simpson (RS): Is there an inherent assumption that there is always on-internet connectivity? If not, then there are a few reasons that you always would want a .local The "disconnected home". DT: If there is global one, no reason to use the local one. ??? - chap in white shirt, who systematically refused to say his name: The things that work today are not going away soon: MS, Apple have ways that work for local discovery I want to remond everybody that what drove this market was that ISPs wanted to charge you per address. So ISPs are going to also charge for a slice of global namespace AB: Just as you see a lot of users today who see their television buttons being as default setting; they will also be lazy or unable to change .local-names. SC: I agree with what Dave said, a global name would be preferable except when it is not reliable. Things change over time: get a global name, be disconnected, forget to renew it, ... MT: So you say that you want a way of tying togeyther several names, and then use happy-eyeballs to reach them? SC: Yes, maybe bookmarks should contain both names, and use some intelligence to connect to the one you want. I do not claim to know how to solve this. Marc Andres (was it??) (MA): We are making assumptions. There isn't going to be a name-server in the home? In house devices are more than capable of running a DNS server today. they can answer .local queries, ...., we just need a name service that we can reach into from outside. We need to design the name solution so as to provide an in-house nameserver. Then, you can do the global names: your global names and their mapping to the local names is maintained in-house. SC: That's true, the problem simply is what when the user doesn't have a global namespace. We should sway, for user access, away from names but to service descriptions, rather. Profiles for devices belong with services. (Presentation resumed) next topic: Independent operation: Must: consider independent operation of naming and service discovery. ... Chairs: any comments? no. good. (Presentation resumed) Some security related issues: .local is more link local ... there will be multiple links. the "drive-by" .local problem. Do we need a ULA-like solution for .local? LH: I didn't understand the use of a name that you can't remember or spell. TC: it essentially hidden from the user - we can disvocover it. AB: If we go between our own and parents house, then .local will automatically be able to switch between them if they can switch betyween them For example, if my mother calls me and ask me to pre-heat her oven, I need to go beyond that. The user can still can name the device, but can ULA name space can be problem. Olav Gundarson (OG): You will have conflicts, people would think that you are somebody else, ..., ULAs change while you are away, therefore, the names you thought that you had no longer exist Peter Koch (PK): That said, the second bullet, no reason for this to be a toplevel domain. You are one of the lucky persons for whoim ICANN is not a concern. It can happen under an existing IANA controlled tld. DT: Peter is right You have a well-know thing followed by a random thing. If it looks like an ULA, make it look like an ULA. The response that was made in response to Stuarts mail, the name generated may not be seen buy the user; see a descriptiube string, neither address, name, service name, .... - the service ULA thingie is just an identifier, that can be used to map to a recorded descriptive string. Andrew Sulivan (AS): I want to step up a layer here. The problem we're having is, that we started with a problem that should only be a meaningful identifier in a local scope. Now, we want many local scopes with meaningful identifiers that can be used across scope. We want a global namespace - we've got one, let's use it. If you need a globally unique identifier, use one. And only use globally unique identifiers. As soon as you say "I need to talk to this network over there", we wilkl need to expose it to users, the identifiers. SC: I broadly agree with Sulivan. Comment: .local implies the local link today, but that may not be problematic to extand to stitching together a few links inside the home and have .local cover this. When we have a global name, I'd rather that it be a humanly readable name rather than some hexidecimal vomit TC: Are those names being exposed to users or not? SC: In the example where I want to help my mother do home-automation in her house, "her house" needs to be resembling that, not just some random hex-jibber-jabber. ???: I am not sure that we are solving a problem that real people have. As a general rule, if you want to be printing, yo uwant to print where you are, etc. If you want to have someone print to you from outside, you shall request a global name, and then it is enabled. Dave York?: How Many of us do tech-support for our friends and families? While the random uyser may not be erxposed to things, we will. But, this may be scope-creep. Bob Hinden (BH): I think that we are trying to make it way too complicated. If my TV starts up sayin I can go override it; I do not want to watch my TV from here, that doesn;t mnake any sense. MS and Apple have solutions, let's just extend it over a couple of subnets, that'll be useful. We do not need to solve everything here As Stuart said: names should be simple for users, they can change them if they want, but they may not, or never do that - people do not tend to have 10 refrigirators. RD: I think a couple of thing that people talked about can be fit together, rather being exclusive. I like the ULA idea + putting it in a global part of the namespace. If you do not have a slice of global namespace, then stick it in .fqdn.iana So if my parents want me to connect, I tell them "you have to create a name for that thing" , then have that ULA generated, duplicate-detected, stick in with a name binding. You only generate this when you actually need to type a canonic name. DT: Add to Ralph: one of the things that WindowsOS does is something like a DNA thing, am I on this that or the other network, it will provide different settings; ssid, dns-suffix, ...., if you have a CPE, what to do? Can't do the same as such (default SSIDs, CPEs relaying dns suffixes from ISP, ....) ??? (Woman): I want to make a comment if this is a real problem or not? I think that if we are designing an architecture for the home, we should think about future problems. So, I want to print XXX on my printer in the office, and I am at my parents home. Must be supported. Another comment about global identifiers: maybe now we think that names won't be visible to users, but that may change in the future. SC: A question in my mind: several people talked about globally unique autogen identifiers. It wasn't clear to me if people expected IANA to run a charity-DNS server for the whole planet? Or, if the home gw is authoritative for it - in which case, it is only visible inside the house. AS: if we started a thing which only has meaning on local scope, ... If you have a global name space, just use. TC: So your advice is only using global name space. The question is the the names are going to expose to the users. Even Hunt (EH): There is generally assuming that when you want to turn on a printer, you know where the printer is. Olaf (?): An example, really constrained devices? Power meters, e.g. not necessarily seeing all other traffics. If you want to control, how to do in broadcast/multicst phases? TC: the low power network is out of scope. Assumed to have gateway. Ray: That is out of scope; if you want a low-power network in there, there must be a gateway and that gateway must filter RD: I agree that if there is a name resolution mechanism using a lot of bc/multicast traffic, we need to have a way of seggregating that traffic. Warning that that seggregation may not map the underlyingTim: TC: We talked about identifying borders RD: Well, this is not topological structure, but logical structure/groups that may be entirely orthogonal from topology MT: Even in wifi, multicast is not efficient. might need a way to get around that. RD: If there is a name resolution with a lot of multicast behavior, we need to segment them. the question is the way to do it. .. they are maybe device that span the two networks, one fast, one slow. Can't simply say you can't send packet from the fast to slow. need to be more clever. Some like groupe mechanisms that are not tided to the topology. TC: Must discovery the border. RD: The grouping are more logical grouping. maybe independent of the topology. (Presentation resumes: service Discovery issues) Devices have a range of services available/ constrained devices/ remote service discovery any ideas? SC: The answer is some we mentioned earlier of the DNS delegation. Either query entry the house, or devices in the house pushing data to the repo. on the server. From jabber: Michael Thomas One thing that might be worthwhile bringing up is that one possible mechanism to preserve localization at a remote location is to just become part of the local network, ie, tunnels/vpns TC: I had expected comments on reverse-lookup Chairs: We Should take this off to the list... 16:50 - 17:00 Session Changeover break - zOSPF / v3 as a Homenet protocol (Jari Arkko - 30m) --------------------------------------------------------------------------- draft-arkko-homenet-prefix-assignment-02 Presentation: OSPFv3-Based Home Networking - connect as many boxes as you want, no matter now you connect them. Architecture: OSPF-based home networking two part: ospf, and dns Implementing and sung HOMENET. Two implementations running. early implementation, but running. Enabler for other things: such as CoAP... Draft-02 updates: algorithms to generate ULAs/ replace Prefix allocation algorithms , etc... Prefix Allocation algo. in -02 Overview of the Algorithm... allocations in the algorithm... ULA generation in draft-02... currently, it always genration ulas, because it's easier to implement. ?? (Finnish guy?): That picture you had with the cables and the boxes, is that your mom's network? If it is, then it's your fault, nobody else's mothers network look like that. Bob said before, we shouldn't make everybody elses' home network more complicated because we're geeks. MT (Floor Mike) To respond to that: I think we're only talking abouyt a handful of routers talking to each other. That's certainly that which Benjamin was working about. JA: The practical case is that you have 1-3 links and 1-2 routing devices. Me, I have, I dunno, 15ish routers. That's the point, I don't need to know. MT (Floor mike): Go to ULA Generation slide If we believe that there is ever a case where a host needs to have an ULA and a global at the same time, and we need to be robust to that, I wonder why we do not give the host a prefix? JA: The choice is if we always hav an ULA and if a global, both -- or, if we always have only one, global if possible ULR otherwise. MT (Floor mike): Where are you now? JA: I am probably agreeing with you. RD: I am taking advantage of you, you've done such a great job of implementing. Can you run an experiment with the code in the different modes, and report to us? JA: I can do either, it's easy to implement the OSPF part of it, but the user-side of things is harder. RD: The comment from earler was "this is way too complicated for your mothers network" I am trying to defend you: the underlying network you deploy this on is way complicated, but you manage to put it on uncomplicated devices and you run it in an uncomplicated way - and it just works. So, if there is complications, it's just hidden. JA: That's the idea. you don't need to worry about how it's connected. Lorenzo: My mother is no longe with us, but I have a GF: she has 2 routers, and they were plugged into each other. Both were running NAT, they were plugged into each other and it worked. We then did smth, AND ended up making it break. I support this, we need tools I am on the side on "let's just give them ULAs and multiple global prefixes"? JA: Do you have data on the brokenness of IPv6 when presented with ULAs? SC: We have several million back-to-my-mac users, and that uses ULA as tunnel endpoints. I am not aware of any problems. Lorenzo: Usable prefix: conveys the message that it's bigger. One thing that I didn't notice is, that when you get multiple prefixes, you will need to do soiurce routing. Is it in there? JA: it's not in this draft, not in my implementation. Lorenzo: source + destination routing is needed. ??? from Toshiba: There are can be different network configured separately. We need to connecte them. ???: support having flooding to distribute prefixes. oppose mandating OSPF as routing protocol. JA: do you recommend specified routing protocol, or just disagree with recommending any particular one? ???: we have multiple routing protocol in the first place. MT: maybe you just need a simple flooding protocol + routing protocol. ??? Very supportive of a floodong protocol distributing prefixes; can we get rid of multiple-nat, though. Disagree with mandating OSPF as prefix distribution proitocol, In your own implementation, do you have working rouiting? We should not mandate OSPF, perhaps, as there are plenty of other routing protocols and flooding protocols. Jari: No, most of it, not all [of the routing is in my implementation]. There's code available. I started from scratch. Bernie Volz: Aren't you ending up with ULAs pretty quickly? Especially when your internet goes down. JA: Yes, and we should end up with ULAs all the time. Markus Stenberg (via Jabber) Benjamin's implementation doesn't do it either - but we've thought about it quite a bit. You can do simplified case for home over the general source routing case. perhaps s/over/instead/ Anyway, there are workarounds to make it simpler, but the question is, do we really want general solution or specific one. TC: You said that you had considered some of the architecture documents. Have you been through them to see if you meet all requirements? For example, are you getting the same delegation if you restart, etc? JA: I think that they are satisfied, but I haven't proven it. Benjamin's work has some proofs and analysis so we should look at this. Lorenzo: When you loose a prefix, or a prefix has to be taken away, presumably you tell all routers to deprecate it to their hosts? MT: Our implementation doesn't do it yet, but we've thought about it. JA: Nor mine. If you lose prefix to someone on the same local link as you, no problem - of course, if you lose it to somebody else, then you need to, and all routers in the system needs to know that this thing went away. Lorenzo: My question was more along the line of "you will end up with a lot of deprecated prefixes all the time"? Jari: We try to avoid that, we require non-volatile memory, try to reuse it. Lorenzo: Occasionally, at least, then..... Another question was: what do you mean source-destination routing is not solved? Do we need to solve the whole problem here? The only thing I see is for ingress-filtering, the only thing that we need to solve? Does that make it easier? Why have a routing protocl at all? Well, it does the flooding, but you likely also have an easy way of implementing authentication. You're going to end up inventing 40% of a routing protocol, when all is said and done Teco Boot (TB): If you take out to your neighbour, what happens? JA: Won't be the same aggregate prefix from ISP, algorithm will determine that it can't use the stored prefix and get another one. TB: So there will be disruptions? JA: Yes, but it will recover automatically. The algorithm tracks what you're given from your ISP. If that changes, it will flush, and reconfigure. There's some hysteresis, but I do not recall by exactly how much. Acee Lindem (AL): My wife does occasionally plug into the neighbors wifi ;) In answer to the source-dest problem, in optical networks, people are already doing really elaborate constraints and using OSPF to flood constraint-based routing Everyubody are looking to the Linux forwad model, the table where the source is first, dest is key then normal routing. You could specify something that would plug into that model, and it would be fairly simple. BH: Mini OSPF tutorial: it's a distributed database that uses flooding ,very efficient. Then, you take that database and run Dijkstra on it. You can distribute other kinds of data using OSPF, for example. The first instance implement of ARPA net was run on really really constrained devices. You shouldnt for a home network with Gbps links and machines like this, be afraid of this complexity. Can also use this for distributing a name database around. Don't go try to recretate it, it can work veru well in this environment. JA: very efficient but very complicated. In early days, it still worked. so no need to be afraid of efficiency. Ashok Narayanan: The point about the neighbors network is actually a bigger deal. If somehow you end up in the situation that you connect to your neighbors netwoirk and autoconf IPv6, thden to your own network, and confgirue IPv6..... MT: You are hitting border discovery.... ???: I think that if you do routing autoconfiguration, you magnify your problems => Discusses DNS Discovery in Draft-02 Experience... Interactions with other parts... Topics for Further discussion 1,2... DT: The obvious alternative to this is to use DNSDD to discover DNS servers. Use service discovery to discover DNS servers JA: Do current hosts do that? MT: This would be a v2 solution - v1 is "do that which works with current hosts" DT: Request explanation Lorenzo: New LSA type? Need to flood a lot of things around SC: I did have this idea many years ago that you could disvover your DNS server recursively the way you discover everything else.... We're inventing something new, and that may have been the point that Dave was trying to make? 17:30 - 18:00 Security Border Discovery (Erik Kline - 30m) ------------------------------------------------------------- draft-kline-default-perimeter-00 to discover administrative boundaries. Scope and Terminology... tried to limit the scope, terminology... Signals we can use... Erik Kline (EK): The documented confused, I'm also confused which ways to take. Richard: I think the document is very well. when you are saying bridge, you mean layer2? Ray B: If I plug the WAN port of my airport express into my LAN, then what happens? It should not be, always, an external border? EK: Depends on what stance you take. Default open/default-closed. Point was that if a (homenet) routing protocol adjacency is established over an interface, then it's internal. Michael Richardson (MR): Read the doc, very well. When you say "come up bridge", do you mean that you have 5 ports on a device and they come up and you bridge them all together until you figure out that one of them is your uplink? EK: Yes, essentially. If you consider them bridged, then you don;t have to route until you have to route [??] MR: Write down suggested heuristics, we may have to argue over the prioritization. It is probably not that important that we standardize completely, vendors can innovate, but we need to say that "this won't lead to a wrong configuration, but if a vendor does differently it'll need to think". Need to cross with the architecture document, what comes up when a device boots, for example, and in what order? As for open-or-close, it depends on nature of links, devices, .... I think it's fine to default to closed, ??? (Chen micro?): When you buy a computer from a store, it should default with all turned on or all turned off? There's no A/V that's going to keep you protected. Keep things turned off, turn on when you need them, then off. Start in default closed configuration. EK: You are in default-closed, and interior router. You hear stuff on your interface, a homenet rp, do you realize and trust that you are now an interior router and should "open"? MT: Today with IPv4, the WAN link is always a natted firewalled interface That is the default closed. ??? (Chan micro) That's not closed, that's wide open A NAT doesn't provide much, if anything, in form of protection. Considering that to be some layer of protection is stupid, we need to stop doing that. Lorenzo: What's a WAN interface? EK: That's a plug with a label saying WAN on it ;) Product-defined interfaces. Lorenzo: Isn't it the goal of having all interfaces as equal? If so, then we can't use these definition. Realms rather than ïnternal/external ???: You want to treat the underlying link that a VPN goes over as an interior link? Chairs: Take to list please Slide: what to do with IPoE? MT: Seems that we are moving towards a flooding protocol for distributing prefixes, not PD inside the home Lorenzo: There are several in-house devices in Japan that are running PD. ??? (another chap who didn't say his name): Half the devices do PD MT: They should stop. EK: If you do that, you are not a homenet router. Slide: Additional considerations ??? (not said his name eiter): Back to the VPN issue EK: Do you want devices inside your home to be able to connect through the VPN to your office? EK: Another thing, the issue of convergence time: when can I decide that I have learnt what I could learn from this netweork? 18:38: Chairs cut queue, meeting ends.