home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ngtrans / ngtrans-tacit-minutes-95apr.txt < prev   
Text File  |  1995-05-27  |  10KB  |  279 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Tony Hain/LLNL - ESnet
  6.  
  7. Minutes of the New Generation Transition Working Group (NGTRANS) and the
  8. Transition and Coexistence Including Testing BOF (TACIT)
  9.  
  10. The NGTRANS Working Group met in two sessions at the Danvers IETF
  11. meeting.  The first meeting was held on Monday morning, and the second,
  12. a joint meeting with the TACIT BOF, was held on Wednesday afternoon.
  13.  
  14.  
  15.  
  16. First Session -- Monday
  17.  
  18.  
  19. There were approximately 120 attendees.
  20.  
  21. Tony Hain opened the meeting noting that the goal of the meeting was to
  22. address outstanding issues with the Internet-Draft ``Transition
  23. Mechanisms for IPv6 Hosts and Routers,'' in preparation for a working
  24. group last call and forwarding that document on the standards track.
  25.  
  26.  
  27.  
  28. Outstanding Issues
  29.  
  30.  
  31. Bob Gilligan lead a discussion of the document.  He asked the group for
  32. issues that were outstanding.
  33.  
  34. The group raised the following issues:
  35.  
  36.  
  37.   1. Can an IPv4 compatible address be assigned to IPv6-only nodes?
  38.  
  39.   2. IPv4 loopback addresses as an IPv4 compatible address.
  40.  
  41.   3. Dealing with RFC 1597 networks during transition.
  42.  
  43.   4. Traceroute visibility -- is there need for it?
  44.        o If yes, how?
  45.        o If yes, in this document?
  46.  
  47.   5. Implementation status (discussion of which was delayed until the
  48.      future joint NGTRANS/TACIT meeting).
  49.  
  50.   6. Should well known tunnel addresses be defined in the draft
  51.      specification?
  52.  
  53.  
  54. Discussion
  55.  
  56. The outstanding issues were discussed.
  57.  
  58.  
  59. Issue One
  60.  
  61. Can an IPv4 compatible address be assigned to IPv6-only nodes?
  62.  
  63. It was noted that, at the interim IPng meetings at Xerox PARC, it was
  64. decided to define IPv4 compatible addresses for tunneling, as opposed to
  65. their previous usage that defined translation which was judged too
  66. complex and was changed.
  67.  
  68. This is addresses of the form ::<IPv4>.
  69.  
  70. It was noted that if IPv6-only nodes would not need an IPv4
  71. compatibility address, a regular IPv6 address should be used.  Ross
  72. Callon noted that if you have a compatibility address you must be a dual
  73. stack system (IPv4 and IPv6) and know how to do auto encapsulation.
  74.  
  75. Jim Bound noted that the answer to the question is ``no.''
  76.  
  77. Ross Callon noted that real IPv6-only systems needed real IPv6
  78. addresses.
  79.  
  80. Bob Gilligan noted that this usage (of IPv4 compatible addresses) was a
  81. transition mechanism only, but a system must have one of these addresses
  82. if it is a tunnel end point.
  83.  
  84. The issue was concluded with a clear understanding that IPv4 compatible
  85. addresses can not be assigned to IPv6-only nodes.
  86.  
  87.  
  88. Issue Two
  89.  
  90. IPv4 loopback addresses as an IPv4 compatible address.
  91.  
  92. In IPv4 implementations, the address 127.0.0.1 is a loopback address.
  93. What does the IPv6 address ::127.0.0.1 mean?
  94.  
  95. Someone noted that the address is needed for application compatibility
  96. (which was later challenged by Mike O'Dell, but not resolved).  Another
  97. noted that the semantics meant simply to tunnel to oneself, and there
  98. are no other valid uses.
  99.  
  100. As a side note, it was noted that an address of the form 1234::127.0.0.1
  101. was a legitimate IPv6 address, not a loopback address, which led to the
  102. comment that it was always a mistake to guess a function or meaning for
  103. an IPv6 address from looking at only some lower part of it.
  104.  
  105. Bob Gilligan contended that the loopback address did not need to be in
  106. the draft, but that it could be in the draft where the dual mode
  107. specification is to make it clear that it is only an IPv4 mechanism.
  108.  
  109. It was then noted that in the future a profile specification might be
  110. needed, and that this would be appropriate to be addressed then.
  111.  
  112. Allison Mankin noted that it would be best to get some transition
  113. experience first, before such a document.
  114.  
  115.  
  116.  
  117. Issue Three
  118.  
  119.  
  120. Dealing with RFC 1597 networks during transition.
  121.  
  122. Someone asked if networks using a private IPv4 address space, such as
  123. the address blocks defined in RFC 1597, would be dealt with by the
  124. transition mechanisms.
  125.  
  126. The answer is that this specification was not designed to address the
  127. issue of private IPv4 address spaces.  Sites with private address spaces
  128. may use the techniques outlined in the specification, but this would not
  129. make their private address spaces globally reachable.
  130.  
  131.  
  132.  
  133. Issue Four
  134.  
  135.  
  136. Traceroute visibility -- is there need for it?  If yes, how?  If yes, in
  137. this document?
  138.  
  139. This subject was discussed briefly to get a start for future discussion
  140. at the joint NGTRANS/TACIT meeting.
  141.  
  142. Over an IPv6 path that is tunneled through an IPv4 network (or path),
  143. the IPv4 routers would not be visible to a traceroute.  It was noted by
  144. Bill Manning that previous experience, e.g., BGP4 and the MBONE, shows
  145. that the tunneled portion should be treated just like a point-to-point
  146. link, and should be thought of as just that for an IPv6 traceroute as
  147. well.
  148.  
  149. Several ways were hinted at as to how to show the hidden tunnel path,
  150. including one which had the boundary points (both going into and out of
  151. the tunnel) noting in their ICMP response that there was an IPv4 tunnel
  152. being traversed, so that an explicit traceroute of that v4 path could be
  153. done if desired.
  154.  
  155. The discussion was then postponed for the joint meeting.
  156.  
  157.  
  158. Issue Five
  159.  
  160. Implementation status.
  161.  
  162. Discussion of this was delayed until the future joint NGTRANS/TACIT
  163. meeting.
  164.  
  165.  
  166. Issue Six
  167.  
  168. Should well known tunnel addresses be defined in the draft
  169. specification?
  170.  
  171. This issue is whether a well known IPv4 address for IPv4-to-IPv6 border
  172. routers should be published in the draft specification, in some sense as
  173. an ``anycast'' equivalent function.
  174.  
  175. Mike O'Dell noted that it would have to be a network prefix, not a host
  176. address, as some internal routing protocols (e.g., RIP) would not be
  177. able to advertise it otherwise.
  178.  
  179. Ross Callon asked if there should be a tunneling redirect.   The
  180. consensus was ``no.''
  181.  
  182. Bob Gilligan stated the assumption of global connectedness of IPv6 for
  183. the single well known advertisement, to which Matt Crawford responded
  184. that one day it might be and the next day it would be divided, hence
  185. busting this assumption.
  186.  
  187. Bob reasked his question of whether the well known address should be in
  188. the draft.
  189.  
  190. The question was then asked, what source IPv4 address is used in
  191. tunneled packets sent by the border router?  Should it be the well known
  192. address or the border routers own IPv4 address?
  193.  
  194. Mike O'Dell challenged wiring this address into the draft saying that it
  195. would cause future problems.
  196.  
  197. Ross Callon favored including it as a low priority route when other
  198. methods of discovering the boundary router(s) fail.
  199.  
  200. There were various ideas of what methods might be used to find a tunnel
  201. address.
  202.  
  203. Mike O'Dell then restated that it was a bad idea to build in a special
  204. hack for a particular network.
  205.  
  206. Someone asked if there was really enough of a problem that we need an
  207. automatic mechanism?  It was noted that this address was really more
  208. like an ``anycast'' address.  Defining it as a well known global address
  209. could be a problem.
  210.  
  211. Someone pointed out that one could get an address from a configuration
  212. server, e.g., DHCP. Bob Gilligan noted that whatever, there needed to be
  213. an address, or a manual configured address, or a new protocol defined.
  214.  
  215. To specify the well known address might mean more complexity in
  216. configuring.
  217.  
  218. Allison suggested that a small (one page) Informational RFC defining the
  219. address be published.  This document would be used for deployment
  220. testing.  The transition mechanism document would explain the mechanism
  221. of a tunnel logical address, but not specify that address.  There was
  222. general consensus for this approach.
  223.  
  224.  
  225. Second Session -- Wednesday
  226.  
  227. This was a joint meeting with the TACIT group.
  228.  
  229. The meeting was opened by Tony Hain, stating the goal was to address the
  230. need for traceroute visibility and finish the mechanisms document.
  231.  
  232. Bob Gilligan reviewed the tunnel visibility options:
  233.  
  234.  
  235.  
  236.  Option 1:  Blind tunnel.  Always ignore lower layer.
  237.  
  238.  Option 2:  Encapsulating border.  Black hole errors in the tunnel
  239.  
  240.  Option 3:  Encapsulating border.  Returns error messages for each IPv4
  241.             point in tunnel (requires soft state).
  242.  
  243.  Option 4:  Special message at borders.  Extension to ICMP to mark tunnel
  244.             boundary and return far end address.
  245.  
  246.  
  247. Alex Conta proposed a special ICMP message for traceroute which would
  248. use a IPv4 format ICMP message to cross the border.
  249.  
  250. The discussion questioned the validity of using ICMP, as some vendors
  251. would special case the message and not return a valid indication of
  252. network characteristics.
  253.  
  254. Someone raised concern that soft-state would be required for path MTU in
  255. any case, so why not add it for ICMP errors?
  256.  
  257. Several comments were made that were sympathetic to defining a general
  258. ICMP extension that would indicate that an error occurred on entry to a
  259. tunnel, the type of the tunnel, and the endpoint of the tunnel.
  260.  
  261. There was general consensus that this document did not need to define a
  262. mechanism for tunnel visibility at this point.  There was also consensus
  263. that treating IPv4 as a special subnet type is a bad idea.
  264.  
  265. Concerns were raised about the mechanism of maintaining error state
  266. information about tunnels.  Problems could be caused if this information
  267. becomes stale.  Some people also felt that maintaining error state
  268. information about a tunnel would be complex to implement, and it was
  269. unclear what value it would provide.
  270.  
  271. Bob asked if this section should be removed from the document?  There
  272. was general consensus to remove the sections of the document pertaining
  273. to maintaining tunnel error state and ttl mapping.
  274.  
  275. There was consensus that after these changes are made, the document
  276. could be put up for a last call and then forwarded onto the standards
  277. track.
  278.  
  279.