home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipngwg / ipngwg-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  18KB  |  559 lines
  1. CURRENT MEETING REPORT
  2.  
  3. Reported by Bob Hinden, Ipsilon
  4. Minutes of the IP: Next Generation Working Group
  5.  
  6. Agenda
  7.  
  8.    Bash Agenda
  9.  
  10.    Status of Base set of Docs
  11.  
  12.    Status of WG Last Called Docs
  13.  
  14.    Changes in IPv6 and ICMP Specs
  15.  
  16.    Status of other IPv6-over-Foo Docs
  17.  
  18.     Token Ring
  19.     FDDI
  20.     PPP
  21.     ATM
  22.     other
  23.  
  24.    Multi-Homed Hosts
  25.  
  26.        Unique link-local address
  27.        other issues
  28.  
  29.    PMTU Discovery
  30.  
  31.    Tunneling specification
  32.  
  33.    Anycast usage by Hosts
  34.  
  35.    API Specification
  36.  
  37.    ICMP Echo Response Truncation
  38.  
  39.    What Pieces are Left?
  40.  
  41.     FTP
  42.     Header compression
  43.     Multicast (son of RFC1112
  44.     Multihoming
  45.     Routing Protocols
  46.     MIBs (many?)
  47.     Service Location Protocol
  48.  
  49.    IPng Area Conclusion
  50.  
  51.    Status of 6-Bone / Testing & Deployment
  52.  
  53.    Status of Implementations
  54.  
  55.  
  56. Introduction
  57.  
  58. Steve Deering introduced meeting.  He reviewed the agenda and asked for
  59. additional topics to be added to agenda.
  60.  
  61.  
  62. Status of Base set of Docs
  63.  
  64. Bob Hinden reviewed status of the base documents.  The following
  65. documents were approved by the IESG and as of last week are at the RFC
  66. editor waiting for publication as RFC's:
  67.  
  68.  Proposed Standard
  69.  
  70.      "Internet Protocol, Version 6 (IPv6) Specification"
  71.  
  72.      "IP Version 6 Addressing Architecture"
  73.  
  74.      "DNS Extensions to support IP version 6"
  75.  
  76.      "Internet Control Message Protocol (ICMPv6) for the Internet
  77.       Protocol Version 6 (IPv6) Specification"
  78.  
  79.  Informational RFC
  80.  
  81.      "An Architecture for IPv6 Unicast Address Allocation"
  82.  
  83. After the meeting the RFC Editor indicated he expects to release these
  84. documents as RFC's by the end of the year.
  85.  
  86. The following documents were previously recommended by the working group
  87. to be published as RFC with the indicated status:
  88.  
  89.  Proposed Standard
  90.  
  91.      "An IPv6 Provider-Based Unicast Address Format"
  92.  
  93.  Experimental
  94.  
  95.      "IPv6 Testing Address Allocation"
  96.  
  97. The IESG did not approve these documents.  The IPng w.g. chairs have
  98. written and sent (with a cc: to the IPng w.g.) a response to the IESG
  99. comments.  The reply responds to the issues raised by the IESG which the
  100. chairs believe represents a misunderstanding with the motivation behind
  101. the design choices.  The IPng working group chairs believe that these
  102. document should go forward.
  103.  
  104.  
  105. Status of WG Last Called Docs
  106.  
  107. The following documents have completed working group last call:
  108.  
  109.      "A Method for the Transmission of IPv6 Packets over Ethernet Networks
  110.  
  111.      "Neighbor Discovery for IP Version 6 (IPv6)"
  112.  
  113. There were no comments received during the last call or at the meeting.
  114. The chairs will forward these documents to the IPng Area Directors with a
  115. recommendations that they become Proposed Standards.
  116.  
  117.  
  118. Changes in IPv6 and ICMP Specs
  119.  
  120. Steve Deering summarized the editorial changes and protocol changes
  121. agreed to by the working group at the Stockholm IETF meeting which made
  122. to these documents as part of submitting them to the RFC editor.
  123.  
  124. IPv6
  125.  
  126. 1) Headers and options must be processed in order, not in the order
  127. picked by receiver.  Important to preserve semantics specified by sender
  128. and to make it easier to add new kinds of headers and options in the
  129. future.  There are security issues in how headers/options are processed,
  130. but options must still be processed in order.
  131.  
  132. 2) Description of jumbo payload options made clearer.  Length includes
  133. length of header and all options.
  134.  
  135. 3) Routing header changed to allow final destination to skip the routing
  136. header if it does not know about a new type of routing header.  This was
  137. agreed to at the Stockholm meeting.  Also added examples and text to
  138. describe how the routing header should be processes.
  139.  
  140. 4) Fragmentation section augmented with additional text to describe how
  141. it works and how suggested mechanisms work.
  142.  
  143. 5) Added requirement that all nodes must be able to reassemble packets
  144. 1500 bytes long.  Min MTU still 576.
  145.  
  146. ICMP
  147.  
  148. 1) Deleted description of Pseudo header and replace it with a pointer to
  149. the pseudo header in the base IPv6 document.
  150.  
  151.  
  152. Status of other IPv6-over-Foo Docs
  153.  
  154. FDDI:  Same state as Ethernet.  Ready to do last call.  Working group
  155. chairs will issue working group last call.
  156.  
  157. Token Ring: Status unknown.  Author did not attend.  Will check with
  158. author then do a last call.
  159.  
  160. PPP: Need to get a code point.  Document editor will ask Internet AD to
  161. get a code point.  Dimitry Haskin will write a IPv6overPPP document.
  162.  
  163. ATM: Work going on in IPoverATM w.g.  There are several proposals.
  164.  
  165. Other: AppleTalk?  HIPPI?  FiberChannel?
  166.  
  167. Discussion about AppleTalk.  There is a old working group and a draft
  168. (expired?).  We need to find this draft and do a IPv6overAppleTalk
  169. version.  Chairs will talk to Internet AD's.  AppleTalk Forum may have
  170. started doing an IPv4 version, but did not complete it.  This document
  171. appears to be harder to write than the Ethernet/FDDI versions.  Brian C.
  172. this is an IPv6overPropritary protocol, maybe we don't have to worry
  173. about it.  Deering mentioned that Appletalk was the reason to have 576
  174. MTU.  It would be very unfortunate if we don't end up doing IPv6 over
  175. Appletalk.  Running IP over Appletalk is also very common.
  176.  
  177. No plan to do IPv6 over SLIP.
  178.  
  179.  
  180. Multihomed Hosts
  181.  
  182. Multihomed hosts need to have an unique interface token for of their
  183. interfaces on the same link.  One way to accomplishing this is to add a
  184. unique value (such as an interface number) to link local address.  There
  185. was not a consensus on this approach.  A number of questions and issues
  186. were raised, and further discussion was deferred to the mailing list.
  187.  
  188. KRE said w.g. need to define what bits are in the address format.  Does
  189. not need to define the contents of the field.  Nordmark said that it was
  190. not clear what is the advantage of this approach.  Doesn't think this
  191. would make multihomed easier.  It was also pointed out this approach
  192. has a conflict with duplicate detection in ND.  Gilligan mentioned that
  193. new API spec. has some features with make multihomed easier.  The feature
  194. depends on each interface having unique addresses (not same link local
  195. address).  KRE said he was not sure the API interface alone is sufficient
  196. to solve this problem.
  197.  
  198. Long discussion.  Important to have overall solution.  This proposal only
  199. helps host differentiate it's own interface address.  It does not help
  200. host know which interface to use when going to a specific off link
  201. destination.
  202.  
  203. No consensus on this approach.  We need a document which covers the whole
  204. issue. KRE agreed to write a draft.
  205.  
  206. Dan McDonald, Jim Bound (and other people from Digital) are also working on
  207. a multihomed proposal.
  208.  
  209. Suggestion that this should also cover multiple interfaces on same link.
  210.  
  211.  
  212. PMTU Discovery / Jack McCann
  213.  
  214. Started with RFC1191.  Took out IPv4 specific pieces which include:
  215.  
  216.      router specification
  217.      DF bit
  218.      TCP MSS
  219.      old stype DGTP messages
  220.      plateau tables
  221.  
  222. What is left:
  223.  
  224.      definition of path :  src, dest, flow-id, routing header info
  225.      Packet too big message
  226.      detecting MTU increases (timers)
  227.      implementation suggestions
  228.  
  229. This document also applies to multicast.  Note need to do PathMTU
  230. discovery for local link destinations.
  231.  
  232. No issues raised.  Chairs will do a working group last call when next
  233. version of the internet draft is out.
  234.  
  235.  
  236. Anycast usage by Hosts
  237.  
  238. Currently anycast addresses can only be assigned to routers.  Discussion
  239. on mailing list about also assigning anycast addresses to hosts.  Anycast
  240. are desirable powerful tool, but are also dangerous due to scaling
  241. problems.  What is next step to use?  Currently hosts can not be members
  242. of anycast groups because routing system needs to learn about anycast
  243. addresses.  Hosts do not currently participate in routing protocols.
  244. Proposal on list to use an extension to the IGMP protocol for hosts to
  245. tell routers what anycast addresses they have (similar to the way they
  246. tell routers which multicast addresses they).  The working group like
  247. this proposal.  It might not even have to define any new messages, though
  248. it may not fit exactly.  The larger questions is how to distribute this
  249. information around routing system?
  250.  
  251. A good next step is a write a document describing how hosts should tell
  252. routers which anycast addresses a host has.  First step should be how
  253. host should use these address, not how to inject into routing system.
  254.  
  255. Someone should write a specification.  Working group is inviting a
  256. document to be written.
  257.  
  258.  
  259. API Specification / Bob Gilligan
  260.  
  261. Reviewed detailed changes in new version of document.  Changes from
  262. previous version of the document include:
  263.  
  264.  -    Changed u_long and u_short types in structures to u_int32_t and
  265.       u_int16_t for consistency and clarity.
  266.  
  267.  -    Added implementation-provided constants for IPv4 and IPv6 text
  268.       address buffer length.
  269.  
  270.  -    Defined a set of constants for subfields of sin6_flowid and for
  271.       priority values.
  272.  
  273.  -    Defined constants for getting and setting the source route flag.
  274.  
  275.  -    Define where ansi prototypes for hostname2addr(),
  276.       addr2hostname(), addr2ascii(), ascii2addr(), and
  277.       ipv6_isipv4addr() reside.
  278.  
  279.  -    Clarified the include file requirements.  Say that the structure
  280.       definitions are defined as a result of including the header file
  281.       <netinet/in.h>, not that the structures are necessarily defined
  282.       there.
  283.  
  284.  -    Removed underscore chars from is_ipv4_addr() function name for
  285.       BSD compatibility.
  286.  
  287.  -    Added inet6_ prefix to is_ipv4_addr() function name to avoid
  288.       name space conflicts.
  289.  
  290.  -    Changes setsockopt option naming convention to use IPV6_ prefix
  291.       instead of IP_ so that there is clearly no ambiguity with IPv4
  292.       options.  Also, use level IPPROTO_IPV6 for these options.
  293.  
  294.  -    Made hostname2addr() and addr2hostname() functions thread-safe.
  295.  
  296.  -    Added support for sendmsg() and recvmsg() in source routing
  297.       section.
  298.  
  299.  -    Changed in_addr6 to in6_addr for consistency.
  300.  
  301.  -    Re-structured document into sub-sections.
  302.  
  303.  -    Deleted the implementation experience section.  It was too
  304.       wordy.
  305.  
  306.  -    Added argument types to multicast socket options.
  307.  
  308.  -    Added constant for largest source route array buffer.
  309.  
  310.  -    Added the freehostent() function.
  311.  
  312.  -    Added receiving interface determination and sending interface
  313.       selection options.
  314.  
  315.  -    Added definitions of ipv6addr_any and ipv6addr_loopback.
  316.  
  317.  -    Added text making the lookup of IPv4 addresses by
  318.       hostname2addr() optional.
  319.  
  320. A few issues were brought up in the resulting discussion:
  321.  
  322.  -    Matt Thomas suggested that in addition to the global variables
  323.       ipv6addr_any and ipv6addr_loopback, systems should also
  324.       provide constants for that can be used for initializing IPv6
  325.       address variables to these values.
  326.  
  327.  -    A number of people suggested that systems should be allowed to
  328.       use the all-zeros IPv6 address as the value for
  329.       ipv6addr_any.
  330.  
  331.  -    Erik Nordmark suggested that the return parameter to the
  332.       hostname2addr() function be changed to include the address
  333.       lifetime (TTL) which is stored with the address in the DNS.
  334.       This would provide applications with the information they need
  335.       to know when to stop using an address.
  336.  
  337. Bob agreed to make these changes and re-issue the internet-draft.
  338. After that, a working group last-call will be held to promote the specification
  339. to Informational RFC.
  340.  
  341.  
  342. ICMP Echo Response Truncation
  343.  
  344. Text should be changed suggest to hosts should try to send back all data.
  345. Document editor will talk to RFC editor to see if this change can be made
  346. before RFC is published.
  347.  
  348. [Should I include this section]
  349.  
  350.  
  351. What Pieces are Left?
  352.  
  353. This working group should deal with: FTP, header compression, multicast,
  354. multihoming, Brian Carpenter suggested we look at list in RFC 1752 for
  355. topics to be addresses.
  356.  
  357. FTP
  358.  
  359. Discussion about using FooBAR.  Some input that might be better to include
  360. names instead of addresses.  Needs to be looked at again.
  361.  
  362. Routing Protocols
  363.  
  364. RIP, OSPF, IDRP, InterDomain (IDRP or BGPng), Multicast Routing?
  365.  
  366. MIBs
  367.  
  368. Dimitry Haskin has a private MIB for v6, is willing to propose it to the
  369. w.g.
  370.  
  371. IESG started working group in internet area to do IPv6 MIBs.  Dave
  372. Arneson is chair of this group.  Name of group is ipv6-mib w.g.
  373. Subscribe by sending email to:
  374.  
  375.      ip6mib-request@research.ftp.com
  376.  
  377. There is a document archive at:
  378.  
  379.      ftp://research.ftp.com/pub/ip6mib/archive
  380.  
  381.  
  382. Service Location
  383.  
  384. Important for plug and play operation.  Current working group working on
  385. service for IPv4.  Charlie Perkins thinks it would be easy to adapt for
  386. IPv6.  Some question about using names instead of address in service
  387. location protocol.  Deering suggest when group produces protocol for
  388. IPv4, we should look at it see how it applies to IPv6.
  389.  
  390.  
  391. Mobility
  392.  
  393. Assigned to Mobile IP group.  Our goal is that every IPv6 host can be
  394. mobile and know how to talk to a mobile host.  Nice to eliminate triangle
  395. routing problem too.  Charlie Perkons has written a draft.
  396.  
  397.  
  398. Dynamic DNS
  399.  
  400. New Lifetimes in DNS
  401.  
  402. The issue is whether we need lifetime fields in the DNS to
  403. handle renumbering or if it is sufficient to overload the cache TTL
  404. values for this purpose.
  405.  
  406. A second point/question was whether the standard gethostbyname()-type API
  407. routines should be changed to return a TTL as well, so applications could
  408. determine how long the addresses they cache are valid.
  409.  
  410.  
  411. Tunneling Specification  / Alex Conta
  412.  
  413. Presented model for IPv6 tunnels, each tunnel is only one directions.
  414. Showed effect on protocol modules and packet flows through system.
  415.  
  416. Specification does not have any association between hop-limit of
  417. encapsulated packet and tunnel header.  Results in having to limit number
  418. of recursive encapsulations because it will not detect tunnel routing
  419. loops.  Discussion on how tunnel destination option works.  Some
  420. question if it is really necessary.  Continuing working on this on the
  421. mailing list then do a last call.
  422.  
  423.  
  424.  
  425. Status of IPng Area
  426.  
  427. Steve Deering reported on lunch meeting w/ IPng area directors and
  428. Internet Area and Routing AD on discussion when IPng area concludes.
  429. Then the IPng working groups will move into appropriate area.  IPng will
  430. move into Internet area.  AddrConf will conclude and work will move into
  431. IPng working group.  NG-Trans will move into Ops area.  Sue Thompson will
  432. be primary AD for the IPng working group.
  433.  
  434. Working group also thanked Scott Bradner and Allison for their work as
  435. Internet AD's.  They did a great job!
  436.  
  437.  
  438. Implementation Status / Questions
  439.  
  440. SD mentioned again the importance of IPv6 extension headers be processed
  441. in order.
  442.  
  443. To subscribe to IPv6 Implementors list send email to:
  444.  
  445.     ipv6imp-request@munuari.oz.au
  446.  
  447. Request to add notice of this list in IPng list mail signatures, in the
  448. charter, and on the IPng web pages.
  449.  
  450. IPng bakeoff will be held February 6-10 at the University of New
  451. Hampshire.  There is a small charge to cover food and other minor
  452. expenses.
  453.  
  454. IPv4 mobility group approved the general direction of IPv6 mobility
  455. specification.  It is important that every IPv6 node support mobility.
  456. Time for Implementors to look at current draft.  Charlie Perkins
  457. described the features of this draft.  IPv6 Mobility draft written by
  458. Perkins.
  459.  
  460. Deering suggested that it would be good for current routers to be
  461. assigned native IPv6 address and set up tunnels to other similar nodes.
  462.  
  463. Dimitry Haskin asked if any provider wanted to donate any links for IPv6
  464. native testing.
  465.  
  466. Jim Bound reported that he thought that ISI will do a RIPng and IDRP.
  467.  
  468. Deering mentioned the test address allocation document and suggest that
  469. people use it to get native IPv6 addresses.
  470.  
  471. Suggestion to add list of current IPv6 hosts on IPng web page.  Bill
  472. Manning had previously volunteered to do initial IPv6 DNS.  Bob Hinden
  473. volunteered to have people install machines at Ipsilon to be on the
  474. Internet.  Geert Jan de Groot, RIPE NCC, volunteered to become the first
  475. root server for the IPv6 6-BONE.  Discussion of approach to use a new
  476. root domain for experimentation.  Goal of group is to set up 6-BONE by
  477. the next IETF meeting.
  478.  
  479. Discussion about what IPv6 features should be tested during
  480. interoperability testing.  The group came up with the following list:
  481.  
  482.    o Base IPv6
  483.    o Option Processing
  484.    o Fragmentation & Reassembly
  485.    o MTU Discovery (unicast & multicast)
  486.    o Routing Header handling
  487.    o Authentication Header
  488.    o ESP Header
  489.    o Neighbor Discovery
  490.       - Router Discovery
  491.       - Address Resolution (normal & proxy)
  492.       - Redirects
  493.       - Prefix Discovery
  494.       - Auto-Configuration
  495.       - Duplicate Detection
  496.       - Neighbor Unreachability Detection
  497.    o Transition
  498.       - Dual IP stack selection
  499.       - Configured Tunnels
  500.       - Automatic Tunnels
  501.    o Multicast (sending, receiving, ICMP)
  502.    o DNS Resolver
  503.    o Routing
  504.       - Unicast
  505.       - Multicast
  506.    o Applications
  507.       - Ping
  508.       - Telnet
  509.       - FTP
  510.       - email
  511.       - NFS
  512.       - vat
  513.       - traceroute
  514.       - X11
  515.       - WWW / HTTP
  516.    o BSD API
  517.    o ICMP Error generation and processing
  518.    o No Next Header
  519.  
  520. This list will be posted on the implementations mailing list and
  521. Implementors should respond with which thing they can be ready to test in
  522. February at UNH.
  523.  
  524. The current Implementors meet and came up with the following subset of
  525. features they thought could be ready for testing in February at UNH:
  526.  
  527.    - base ipv6
  528.    - option processing
  529.    - fragmentation and reassembly
  530.    - mtu discovery (unicast and multicast)
  531.    - routing header handling
  532.    - authentication
  533.    - esp (not)
  534.    - router discovery
  535.    - address resolution (but no proxy yet)
  536.    - redirects
  537.    - prefix discovery
  538.    - stateless autoconfig
  539.    - duplicate detect
  540.    - nud
  541.    - stack selection for dual IP (not an interoperability issue)
  542.    - configured tunnels
  543.    - automatic tunneling
  544.    - multicast (sending, receiving, icmp) (yes, optional for icmp)
  545.    - dns resolver (over v4) (optional, or /etc/hosts6)
  546.    - bsd api (by porting a simple application)
  547.    - ICMP error generation and processing (yes, exercised by testing program)
  548.    - no next header
  549.    - unicast routing (static, then RIP by February)
  550.  
  551.    Test applications:
  552.    - ping, traceroute
  553.    - telnet, ftp (with foobar), email
  554.    - vat/ ivs
  555.    - multicast version of rwhod, mping, mtest...
  556.  
  557.  
  558.  
  559.