Minutes for BEHAVE at IETF-interim-2010-behave-1

Meeting Minutes Behavior Engineering for Hindrance Avoidance (behave) WG
Title Minutes for BEHAVE at IETF-interim-2010-behave-1
State Active
Other versions plain text
Last updated 2011-09-06

Meeting Minutes

   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:

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
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