Minutes for BEHAVE at interim-2012-behave-4
minutes-interim-2012-behave-4-3

BEHAVE Interim meeting, conference call
Thursday, June 21, 7am-9am Pacific Time
chairs:  David Thaler, dthaler@microsoft.com, Dan Wing, dwing@cisco.com
notes by: Senthil Sivakumar

Rechartering discussion
JFTremblay : Is residential NAT part of Sunset4?
Dave: Anything specific to multiple subscribers behind the same NAT is part of
Sunset4.  Anything generic to all NATs is still Behave.

JFT: How about multihoming ?
Dave: Not each and every scenario is discussed and decided. But in principle,
anything subscriber related and address sharing will belong to sunset4.

NAT MIB - Simon
--------------
Simon : Managing multiple multiple NAT instances similar to VRF.
Senthil : There are other scenarios where VRF may not be applicable but
requires managing multiple NAT instances. Dave: Entity MIB should be used in
those cases and normative reference to entity MIB is required in the draft.

Simon : Should we obsolote RFC4008?
Dave: If 4008 is having issues, we should fold in the contents that are useful
from 4008 and deprecate the inidividual MIB objects from 4008. Simon:In 4008
everything is interface bounded makes it difficult for many implementations.
Dave:Then we should resolve the interface specific objects issue in this draft
and obsolete 4008. Senthil: We should find out if there are implementations of
4008 and find that it is useful Simon: There are implementations and people
find it useful in some cases.

Simon: Would like to keep the draft the same until the rechartering is resolved.
Dave: I expect the rechartering to separate the roles of Behave and sunset4 to
happen prior to Vancouver IETF.

Simon : Will separate the draft to have the subscriber related MIB objects in a
separate draft. Simon: Will add the reference to entity MIB.

IPFIX IE's – Senthil
--------------------------
7:35am - Senthil presented his slides

JF: is there a message for de-allocation of port block?
Senthil:  Needs to be added.

JF: need occasional refresh, every 24 hours or 48 hours or something.
Otherwise gets hard to search logs.
Senthil: should we use a 'lease time'?
JF: nobody uses lease time.
Senthil: Will ask the list to determine interest for refresh.

Simon: when subscriber is mapped to a different address (due to ports
exhausted on their primary address), what happens?
Senthil: To accommodate that, next version will add an 'address map' event

Senthil: does this belong in sunset4 or behave?
Dave: not yet known for sure.

FTP46 – Simon
----------------------
Senthil: How would this work if the destination port is not 21?
Simon: Will need to find a way to provision this.

Dave: This sounds like NAT46 scenario.
Simon: This issue is present in a NAT64 deployment that allows the IPv6 users
to run servers. Dave: This look like a datacenter model, it is upto the ISP to
disallow running any servers. JF: Don’t understand how this use case will apply
to a network operator.

Dave: Does active & passive FTP work in this model?
Simon : Active works and passive does not.

Simon : Should this be a WG item?
Dave: This doesn’t belong to the charter as it exists now, but require some
thoughts on the whole on 4to6. Dan:Agree, we should to talk to AD and gauge the
support of the larger community.

Dave: Needs operational consideration section on how the client will know the
servers address and how the NAT46 will be Provisioned in case of non-standard
port. Simon: Agreed

Stateless NAT46 - Simon
-------------------------
Dave : Sounds very similar to SD NAT.
Simon: Where should this work be done?
Dave: More appropriate for sunset4 but whereever the SDNAT, deterministic NAT
logging is done, is also the place for this draft. Dan : Agreed.

NAT64 discovery – Teemu
-------------------------------------
Teemu : Pref64::/n with padded zeros or Pref64::WKA/n with well-known IPv4
address in the RFC6052 location used by the DNS64? Dave: The latter because it
is easier to do the lookup than writing additional code to compare the address
after the lookup. Senthil : Favor the later model.

Teemu : Prioritization of multiple prefixes vs one.
Simon : The operator might reordering for load balancing purposes.
Teemu : Send all of the them to the upper layers as is and then let the
application decide. Simon : Return one prefix with a lower TTL and that gives
the control to the operator to do load balancing. Dan: The home servers can do
whatever they want, operators cannot rely on the behavior of the home servers.
Teemu : Cellular networks don’t have the ability to change the order and this
issue may not apply there. Dan : No, the problem exists in cellular networks
too, phones support tethering. Dave: It appears the only way that would work is
return one prefix with lower TTL if the operator wants control and want to do
load balancing.

Teemu : Connectivity check -  Stun or ICMPv6
Simon – ICMPv6 has many short comings, it is rate limited, some firewalls may
not allow them, can get dropped. STUN/UDP is more reliable. Dave – Why was STUN
chosen in particular? Why not any UDP? Simon – With STUN, you can get a
response to the query to be able to verify. Dave – It is not guaranteed to have
a STUN implementation on the sender but will definitely have ICMPv6. Simon –
Add text to mention that if ICMPv6 is used then the operator should not do rate
limiting.

Teemu – Is a figure required in MSC.
Dave  - Yes it is useful.

Teemu – How often to repeat the query if no AAAA response.
Dave – Is it a no response, or NXDOMAIN or NXRRSET set or no reply? Based on
that you should decide what to do? Should use the TTL in the response to
determine the retry frequency. Dave/Teemu – There is some confusion on the
appendix example of RRSIGs Dan – To provide the updated examples to Teemu on
the RRSIGs.

Teemu – Intermediate DNS servers issue as mentioned in the list.
Simon - Doesn’t apply in this case.

Simon – Security section still does not address his concern, it is still using
the heuristic and is not secured. Dave – Clarify the trust model and explicitly
specify what is trusted and what is not.

Dave – Another revision needed.
Teemu – will publish one by next week.
Dave – will do another WGLC.