Network Layer BOF, Oslo, 13 July 1999 Reported by Evi Nemeth, edited by Brian Carpenter. The IAB held an invitational workshop on the future of the network layer on July 7-9. The BOF was a preliminary report; a draft workshop report will be published asap. Q: - What's the network layer? A: - IP! See slides for details of the preliminary report. Main recommendations: Recommedation on namespace The appointment by the IAB of a panel to make a recommendation to the IETF about: i) whether we should encourage more parts of the stack to adopt a namespace other than the 32-bit numbers, so that a) NAT works 'better', and b) we have a little more independence between the internetwork and transport+above layers; ii) if so, whether we should have a single system-wide namespace for this function, or whether it makes more sense to allow various subsystems to chose the namespace that makes sense for them; iii) and also, what namespace(s) [depending on the output of the point above] that ought to be. Recommendation on RSIP Interesting idea but not fully worked out yet; gives host explicit knowledge of its temporary global address. Premature to recommend as a mainstream direction but resolves some NAT issues. IETF should actively work on RSIP and develop the details and study the issues. Recommendations on IPv6 Finish making automatic renumbering real and credible with TLA addresses, and pursue TLA deployment. NAT (+ RSIP?) is part of the migration path IESG examination of 8+8/GSE area should not disturb ongoing IPv6 work, should use broad expertise, and should liaise with the endpoint namespace panel Recommendations on DNS Don't propose any more fundamental change at this time please. In order to encourage widespread deployment of IPSEC, rapid deployment of DNSSEC is encouraged. Recommendations on routing Automatic IPv6 site renumbering: see above Automatic IPv4 site renumbering: can't do much (installed base, missing IETF effort, PIER conclusions). NAT/RSIP may help. Premature to start more work on next gen routing in IETF. A possible place would be IRTF RRG. Recommendations on Application layer and APIs - Most current APIs (not just sockets) are an obstacle to migration to a new network layer of any kind. IPV6 socket API has steps in this direction. Apps should lose IP addresses (RFC 1900) Have a look at generalising APIs to offer more abstraction Commments from the floor Comment on split DNS - There is a draft called alternate names which is an alternative to split DNS. What's the issue with DNS TTLs, make them a day and it's OK. Answer: we thought that old and new addresses would normally overlap for a long time, but also there might be several renumberings per day and then TTL matters. Q: want clarification, lots of renumbering going on, but why several times a day? Q (Bob Hinden): Renumbering automatically by an ISP is a fantasy, companies wont let it happen. Customer is the bigger fish. ISP might work with customer, but it won't be truly automatic. A: We want renumbering with IPv6 to be a couple of orders of magnitude better/easier than IPv4. Does the phone company ask you when it changes your area code? It's almost the same thing. Q: Was there any talk about how often you need to renumber to get benefits? A: We don't have much experience with renumbering. Once a year, twice a year, once a week, 3 times a day? We don't really know. Steve Bellovin: Foresees a day when charging includes routing advertisements. If we went to a scheme of 8+8/GSE then renumbering is easier, but the A6 record has same property, WAN routing changes on top 8 bytes, local routing and numbering on the low 8 bytes. Q: With millions of DNS updates a day, global reachability and renumbering incompatible. Q (Bob Hinden): The presentation focussed on PCs. A new fleet of wireless always-on mobile devices are coming soon, need to focus on how to handle these and how they fit into the infrastructure. Afraid that the Internet in the middle that works for these guys isn't being addressed. A: The IAB is having another workshop on wireless/mobile issues in the near future. Q: Did anyone talk about maintaining TCP connections across renumbering. A: We talked briefly about it, too hard for the benefit. Q (Eric Brunner): Did the participants have suggestions on where API work should be done. A: not really. We don't often do them in the IETF, but it's not forbidden. Brian: we will produce a report of the workshop, not sure if we should publish the detailed minutes, if so as an RFC or on a web page? Scott Brim: yes please, would love to see context, where was an idea coming from.