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.