Minutes for BEHAVE at interim-2012-behave-4
Behavior Engineering for Hindrance Avoidance
||Minutes for BEHAVE at interim-2012-behave-4
BEHAVE Interim meeting, conference call
Thursday, June 21, 7am-9am Pacific Time
chairs: David Thaler, firstname.lastname@example.org, Dan Wing, email@example.com
notes by: Senthil Sivakumar
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.
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: Dont 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 doesnt 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 dont 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
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
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
Teemu Intermediate DNS servers issue as mentioned in the list.
Simon - Doesnt 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.