BEHAVE Interim meeting minutes, Sept. 17, 2009, 7am-9:10am PDT Attendance was via WebEx screen sharing and PSTN voice Chairs: Dan Wing, dwing@cisco.com, Dave Thaler, dthaler@microsoft.com WebEx recording: https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=40376397&rKey=4126d72ee3b4a9cc Attendees ----------------- Dan Wing (chair) Dave Thaler (chair) Agnes Tow Bo Zhou Cameron Byrne Dan Romascanu Dean Chung Fred Baker Heinrich Haager Hui Deng Iljitsch van Beijnum Jacni Qin Lin Xiao Liu Dapeng Magnus Westerlund Marcelo Bagnulo Philip Matthews Simon Perreault Teemu Savolainen Zhen Cao Notes taken by Dave Thaler draft-ietf-behave-v6v4-xlate-01: Xing Li ---------------------------------------- Multicast packets reference address format docs Marcelo - we should do it in a different document, maybe Stig's Xing - no preference Magnus - reasonable to push out to a separate doc Dan - let's talk about this during the DNS64 update on the agenda Terminology: use of "network-specific prefix (NSP)" vs "LIR prefix" The consensus among those present was to use NSP since it applies better to other cases such as home gateways. The NSP definition still needs some work though. Terminology: use of "mapped" and "translatable" etc The consensus among those present was to not define a new term for normal IPv6 addresses used with stateful translators. The term "IPv4-mapped" conflicts with address range, e.g. in sockets API, and so another term is needed. Comments on draft-ietf-behave-v6v4-framework-01: Gang Chen ---------------------------------------------------------- Today there is no generic term for the concept of translation-in-host. The term "IPv4-adapted-IPv6 implementation" was proposed and discussed. Fred Baker - not sure why it's useful Dave - how about changing "implementation" to "host". Update definition to make it clear it's a term for the host stack, similar to "dual stack host" Fred/Dan - where would this term be used? BIS/BIA update, PNAT There was no consensus reached about whether adding a term to the framework was needed. Christian Huitema was not able to make it to the interim meeting, and enough time was requested for discussion of other documents to fill up the interim meeting, so the discussion on the address-format document was deferred to the next interim meeting. Comments on draft-ietf-behave-v6v4-framework-01: Bo Zhou -------------------------------------------------------- After some discussion, there was consensus among those present that one can't use "translator" in a definition to distinguish between "Internet" and "a network". The motivation for wanting to more precisely define the difference seems to be something about implementation, although others didn't necessarily agree with this motivation. Dave - distinction is far more applicable to a deployer than an implementer Dan - what about just capitalizing "A Network" Discussion of sentence about "stateful doesn't support IPv4-initiation": The concern is this statement doesn't apply to all stateful proposals, e.g. the deprecated NAT-PT. Dan - change to " doesn't support IPv4-initiation" The consensus among those present was to do that. Discussion of ALG in framework section 3.1.5: Some expressed reservations about not wanting to recommend ALGs. Dave - add reference that Dan posted to the list - RFC 4924 section 2.3 The consensus among those present was to do that. draft-ietf-behave-v6v4-xlate-stateful-01: Marcelo Bagnulo --------------------------------------------------------- Some pending updates still need to be added, specifically around fragment & MTU handling. Using the #'s of alternatives from the minutes of the August interim meeting, Iljitsch wants 2 but allow people to do 4, but wants more people to speak up. Dan - chairs can step in and call for consensus. ACTION ITEM: Iljitsch to send summary of question to Dan by next week. Xing - some text should move over to the xlate doc? Marcelo - anything in common should move, anything specific to stateful should stay There was agreement among those present on this. Xing and Marcelo will agree over email on which text needs to move. FTP64 issues: Liu Dapeng ------------------------ The context of the proposal is to introduce FTP client changes that avoid the need for FTP64 in cases where you can change the FTP clients, leaving an FTP64 ALG only when you cnanot. There were three sub-topics... 1) How client uses PASV's response messages IPv4 address The proposal is to just use control channel's IPv4 address. After some discussion this seemed ok, and Iljitsch agreed to make this change. 2) Which try first: EPSV or PASV? Proposal is PASV first then fallback to EPSV This is better if know you're talking to an IPv4 server. The opposite is better if talking to an IPv6 server. Dan - if host/app can learn prefixes, it can tell which case and modify behavior Dave - don't overconstrain, allow both and leave it up to config or heurtistic like dan said 3) ALG considerations Recommend against unless have no choice such as ISP doing translation And perhaps reference RFC 4924 section 2.3 here too? draft-ietf-behave-dns64-00: Iljitsch van Beijnum --------------------------------------------- The only thing needed in DNS64 to make multicast work is a longest prefix match for translation prefixes. Iljitsch will work with Stig and get text to Andrew by next week or so. At the conclusion of the meeting, Dan summarized the list of open issues the chairs need to discuss: 1) IPv4-adapted-ipv6 host terminology 2) IPv4-mapped terminology