Behave Agenda: http://www.ietf.org/proceedings/09jul/agenda/behave.html Chairs: Dave Thaler, Dan Wing Note takers: Ed Jankiewicz, Stuart Cheshire (notes edited by Dave Thaler) Jabber scribe: Dan Wing ============================================================================ Monday Session: ---------------------------------------------------------------------------- Introduction and Agenda Bashing WG Chairs (Dave Thaler) Agenda review, Note Well Revised Charter - added scenarios Existing Milestones SCTP - need review and WGLC TURN on track small open isses TURN-TCP 3 week WGLC Created new milestone dates Another batch for Sept. - basic v6v4 and TCP - are these too aggressive? Marcelo: normative reference to prefix doc, which follows the Sept batch. Should we move out to follow? Fred supports. Dave: stateless, stateful and DNS move out due to normative ref to the prefix doc; will revise and discuss with AD ---------------------------------------------------------------------------- Framework for IPv4/IPv6 Translation Fred Baker http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-00 Why translation? Cases for viable interim approach Fred presented scenarios covering connecting a small network to a larger network, where one is IPv4 and the other is IPv6, where the initiator is one side or the other, etc., giving a total of eight scenarios: 1 v6 network to v4 internet 2 v4 internet to v6 network 3 v4 network to v6 internet 4 v6 internet to v4 network These 4 all require a translator and either DNS64 of DNS46 5-6 are network to network 7-8 internet to internet Target completion date for the framework document is September. Format and usage of address, translation algorithm, maintenance of states, operational modes Stateless (e.g. IVI - CERNET prototype) LIR assigned prefix, deploy v4 servers in v6 network Entice services and clients to move to v6 Stateful - initiation from a client Unsolved problems - multicast and some stateless translation with multiplexing Listed as a September milestone - no reason to delay ? China Mobile; same solution could be used for several scenarios; please clarify in framework; Scenarios are long-term problems, but solutions may evolve Room discussion about why there are so many scenarios. Why not focus on solutions? Dave Thaler explained how different solutions may work for different subsets of the scenarios -- conceptually some solutions may solve a vertical slice through the collection of scenarios, other solutions may solve a horizontal slice across the collection of scenarios. Dan Wing: the scenarios are part of the charter, defines the problems to solve. Solutions can attack one or more scenarios, and there could be multiple solutions for some scenarios. ? what is the definition of v4-only or v6-only? Dave: Need wordsmithing in the framework and stick to one good definition. Implementation only, address only or application only supports one. Some condition forces translation. The Framework ? what is the border between IPv4 network and IPv6 internet? Dave: the border is defined by the network operator, routing tables, etc. ---------------------------------------------------------------------------- IP/ICMP Translation Algorithm (The "stateless" translation approach) Xing Li http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-00 Covered translating from IPv4 ICMP to IPv6, and IPv6 ICMP to IPv4 Transport layer checksum - in SIIT can make address translation checksum neutral In some UDP cases checksum is zero. If >1280 recalculate (configurable) Path MTU IPv4 to IPv6 with DF=1 must send back ICMP packet too big DF=0 add fragmentation header Dave Thaler: Question for Working Group: Should document take any position on checksum=zero, or should it remain silent on the issue? Dave: forcing translator to recalculate creates DOS possibility Magnus: tunneling case; IPv6 disallows checksum=zero. Fred Baker: tradeoff between DOS and host discarding checksum=0; do host implementations do this? We don't know. We need a survey of IPv6 host implementations to see how they actually handle packets with checksum=zero. Iljitsch van Beijnum: IPv6 spec requires valid UDP checksum, so if v4 apps send with zero checksums, and translator does not compute correct IPv6 UDP checksum, then those apps are simply not going to work with IPv6 hosts that follow the spec and verify the received checksums. Is checksum calculation really a potential DoS attack? Maybe fragmentation is. Fred Baker: In routers that just look at headers and forward packet bodies using low-level hardware, having to examine all the packet body bytes in software is a major cost, and forces assembly at the wrong layer. Dave: stateful and stateless Erik Nordmark: Agrees that IPv6 disallows checksum=zero. Is there really real-world evidence of widespread use of IPv4 apps that send with zero checksums? Silent dropping is not really optimal, send ICMP bad parameter message. Suresh: firewalls will drop. Port altering would not be caught if no checksum Hadriel Kaplan: We have real-world evidence RTP apps using zero UDP checksum, and the same apps do in fact also work using zero UDP checksum over IPv6 too. If v4 checksum is 0, lying to calculate one ?: Synthesizing a UDP checksum is arguably wrong, because the translator is effectively vouching for the integrity of the packet data, when in reality the translator has no way to know whether the packet data is corrupted or not, because the packet data arrived without a UDP checksum, so the translator wouldn't know if the data was corrupted. Source address derived from IPv4 source ICMPv4 error message translation V6 to v4 - in general recalculate the checksum, stateless can be neutral Discussions from list: Fragmentation, TCP MSS In current draft scattered, bring together in appendix Higher-checksum handling; for arbitrary addresses transport checksum must be recalculated; Translator ICMP error messages could be a DOS; should be configurable ---------------------------------------------------------------------------- NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Marcelo Bagnulo http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-00 This is the "stateful 6 to 4" translation approach Marcelo showed diagram of NAT64 TCP state machine, establishing and discarding mappings. Tracking of the sequence number? TCP state is expensive If we see bidirectional SYNs go into established state (see State Machine in presentation) See both FINs, got to a 4 minute timeout to discard state After RST, the state machine waits for 4 minutes. If further data packets are seen, connection returns to established state. Fred: can discard on reset? Marcelo: propose to start inactivity timeout (4 min) after RST Lars: why wait for 4 minutes after RST? Joel Halpern: forged RST is a DoS threat Lars: checks on accepting RST; is this up to Behave if TCP doesn't say? Marcelo: reduced timeout allows it to keep working but accelerates teardown if nothing happens, easier to work if you track sequence numbers Fred: mirrors what goes on today in NATs. Cisco NATs validate RST packets, and if they're deemed valid, they discard the connection state. Gregory Lebovitz: This is just to avoid the NAT keeping track of sequence numbers, to reduce state, but lots of reset connections waiting for four minutes to time out may add up to a lot more state. Robert (or Bryan?) Ford: What about out-of-order packets, where an out-of-order data segment arrives after a RST? Reordering may preempt the RST and trigger 2 hour rather than 4 minute timeout; clarify the direction (46, 64 or net/internet) Remi Despres: To restore connection to established state, does data segment have to be in same direction as RST packet, or will opposite direction work? Often data packets in the other direction will already be in flight when RST arrives. Data from the RST side should be the determinate Marcelo: should we/not track sequence numbers? ?: workaround for not keeping sequence numbers, how do you know whether the host does not accept the RST? Dave: this is analogous to NAT inactivity timeouts today Lars: leave it up to the end host and react to what it does. If you track sequence numbers, not much benefit. Marcelo: inconclusive, continue on list Hadriel Kaplan: Isn't this the same problem all large-scale NATs have to solve? This is not specific to v4/v6 translating NATs. Need a generic standard on how to handle ---------------------------------------------------------------------------- Fragmentation and PMTUD Iljitsch van Beijnum What to do when IPv6 host insists on sending 1280 bytes, but IPv4 network sends back "too big" messages, which IPv6 host ignores because it "knows" 1280 bytes is not too big. V4v6 PMTUD classic - RFC 2765 and 2460 If the v6 side defaults to 1280 to avoid PMTUD, can create a PMTUD blackhole. Middle ground - stick to 2765/2460 behavior but translate IPv6 packets with <= 1280 DF=0; >1280 to DF=1; avoid blackhole. Collect fragments and reassemble, if out of order need to buffer Fred Templin: 2460 says IPv6 packets are implicitly DF=1; including fragment header implies DF=0; firewall RFC says it would be ok to filter out ICMP that say packet too big. No way to Erik Nordmark: Redundant translators would not work with this. We want stateless translation so we can have parallel redundant translators. If translator has to make up fragment IDs, then it becomes stateful. Marcelo: this is only how the stateful box handles fragmentation ---------------------------------------------------------------------------- IPv6 Addressing of IPv6/IPv4 Translators Dave Thaler http://tools.ietf.org/html/draft-thaler-behave-translator-addressing-00 General approach to constructing addresses to use in translators Terminology: "IPv4-translatABLE" vs. "IPv4-mappED" addresses. IPv4-mapped applies to stateful as well IPv4-mapped prefix MUST map to a unique IPv4 network; should be possible to distinguish IPv4-mapped vs native IPv6 IPv4-translatable - prefix must be <= 64 bits MUST NOT inject every route in IPv4 internet; SHOULD NOT require code changes in existing host. Some routers reportedly have performance issues routing on more than 80 bits. Fred Baker: Why 80? Why isn't 64 bits the common cutoff for router performance? Dave Thaler: Despite 8+8 addressing, apparently the ability to route efficiently on up to 80 bits is common in routers. Pierre Levis: Should document include 64-bit requirement for stateless autoconf addressing? V6 internet with IPv4 network Requires stateful and IPv4-mapped (network specific prefix) An IPv6 network with IPv4 Internet For IPv4-mapped - default to a well-known prefix, configure network-specific; WKP MUST NOT be advertized into IPv6 internet and should be filtered. Need a new prefix range from IANA IPv4-translatable using a WKP introduces multihoming issue; use a network-specific prefix. Address Format Requirements 1. one-to-one and reversible 2. MUST NOT change meaning of universal/local bit 3. space for multiple translators 4. checksum neutral for stateless 5. SHOULD allow v4 dotted decimal in last 32 bits 6. SHOULD support IPv4 topology hiding 7. MAY hide IPv4 address for "helpful" NATs Fred Baker: how does this play with LIR assigned prefix, following IVI address format? (list of address formats) all meet the stated MUSTs, tradeoffs on the optional goals (see table in presentation) Do we need topology hiding or not? Can we narrow down this list? Open questions: Should we cover encapsulation as well? Joint work with Softwires. Can we deprecate SIIT IPv4-translatable format? Iljitsch van Beijnum: How does this relate to Softwires & encapsulation? Should they be combined? Marcelo: need a recommendation for each solution, to refer to this doc Remi Despres: support joint effort with Softwires Dave: other work blocking on this so should move quickly to RFC; Softwires involvement may complicate and slow down the effort Suresh: need to prioritize optional requirements; throw out some of these and some of the options become superfluous. ---------------------------------------------------------------------------- How Host A learns the IP address of Host B Xing Li http://tools.ietf.org/html/draft-bcx-behave-learn-address-00 Combinations of WKP and LIR assigned prefixes, v4-mapped and v4-translatable addresses If Prefix1 and Prefix2 are both LIR, simple solution Workaround required for Prefix2 WKP Hairpin - not optimal routing For stateless scenario 1 and 2 Prefix 1 LIR is simpler and scalable For stateful scenario 3 Marcelo Bagnulo: Why would one IPv6 host get the synthetic IPv4 address of another IPv6 host? Dave Thaler + Dan Wing: This happens because of application-level referrals (e.g., SIP), where applications pass IPv4 addresses to each other. Suresh: if Prefix1 and Prefix2 are the same, what if there are multiple translators? Hosts need multiple addresses? Dave: stateless, translators could have the same addresses Erik Nordmark: The examples show two IPv6 hosts next to each other. What about when the two IPv6 hosts are far apart across the Internet, behind different translators? Xing Li: In that case there's double translation. ---------------------------------------------------------------------------- Learning the IPv6 Prefixes of an IPv6/IPv4 Translator Dan Wing http://tools.ietf.org/html/draft-wing-behave-learn-prefix-03 Defines a mechanism to allow IPv6 applications to obtain the IPv6 prefix for an IPv6/IPv4 translator, so packets for a priori known IPv4 address can be sent to the translator. This is useful for both stateless and stateful translation DISR: general interest in following translator work Skip to slide 5 - issues Dan proposes to keep DNS and drop the DHCP and RA mechanisms Anyone who disagrees is asked to send feedback to the list ---------------------------------------------------------------------------- host based translation Hui Deng http://tools.ietf.org/html/draft-chen-host-ipv6-ps-00 Most hosts are dual stack; current solutions consider only single stack Host based solution can use the other stack ability IPv4 and IPv6 applications with dual stack host Numerous IPv4 legacy applications, even with IPv6-only connections Compatibility with NAT64 PNAT module in the host PNAT vs DSlite - does not do double translation; send two DNS queries; could support multiple scenarios (DSlite targets v4-v4) Comments: does the network route IPv4? If not why allocate IPv4 address? DNS goes to DNS64 if sent over IPv6-only network. Fred Templin: Is there an implementation of this? Hui Deng: It is in progress, expected end of August. Further discussion Thursday 15:10 ---------------------------------------------------------------------------- Generation of ICMPv6 Echo Replies for Teredo Clients Teemu Savolainen http://tools.ietf.org/html/draft-denis-icmpv6-generation-for-teredo-00 Summary: Observation that Teredo depends on ICMP echo packets not being dropped to find the closest Teredo relay when communicating with a non-Teredo IPv6 destination. ICMPv6 echo reply may be missing with Protocol Translation or through IPv6 Firewall; ping may not be reliable for finding Teredo server Are the assumptions in the draft valid? Is this a real problem? If so, should there be a solution? How should we proceed with draft (Informationa, PS, include in NAT64, behave WG, individual?) Dave Thaler: This is only superficially related to NAT, in the sense that NAT is one case that might cause ICMP packets to be dropped, but it's just one of many cases that cause ICMP packets to be dropped. The v6ops WG, where Teredo documents live, would be a good resource. ============================================================================ Tuesday Session: ---------------------------------------------------------------------------- Accelerating milestones WG Chairs (Dan Wing) Monthly interim WebEx meetings, with updates coincident, until IETF 76 6/4 translator, prefix, DNS64, etc. Naming and Prefix draft adoption prefix draft draft-thaler-behave-translator-addressing-00; relieve Dave as editor, add new editors No comments, 9 folks have read; Consensus to adopt ---------------------------------------------------------------------------- Translator Terminology WG Chairs (Dave Thaler) Define and move on IPv6/IPv4 Translation (or Translator) is generic NAT64, NAT46 when direction of initiation is important add stateful or stateless at the beginning when specific to those so "IVI" -> "Stateless IPv6/IPv4 Translation", "NAT64" -> "Stateful NAT64" Unless strong objections please conform to these There were no objections ---------------------------------------------------------------------------- DNS64: DNS extensions for NAT64 Andrew Sullivan http://tools.ietf.org/html/draft-ietf-behave-dns64-00 From draft-bagnulo-behave-dns64 adopted in San Fran Related to NAT64, but separate proposal Theory of op - simple DNS translation Recent important changes Heavily reorganized, established default algorithm (pending comments and change) Additional section also needs synthesis - made it explicit Mark Andrews: no need to ever do the synthesis; DNS64 is recursive server; clients should go looking for additional section if missing; you should do a AAAA query for every address in the additional section. Do not translate if the additional section has been truncated. Andrew: if there is a recursive server behind you; it has to ask again Mark: yes, that is right to ask again Andrew: this is a kludge already Mark: just leave the additional section alone Andrew: agree there is an issue, we need a detailed discussion on the list. Either add tradeoff text Marcelo: how pervasive are broken clients that don't ask again? This will not work if we don't translate for them. If it is a rare case, we should do the right thing Iljitsch: doing this for name servers, not clients Mark: each name server is a client to the next in chain; synthesizing when you could have gotten real AAAA is propagating broken information; no need to fudge missing data, it is normal to requery for missing additional information Dave: please post alternate arguments Xing Li: for LIR how to prefix; multiple translators - how to select the right DNS Andrew: no text that explains how to ensure that you have the right DNS box to get the right prefix. Xing: missing some info for DNS46 Andrew: this is narrow focus for DNS64, maybe need another draft to expand scope Dave: NAT-PT style state creation? Someone should borrow text and start a NAT46 draft Draft explicitly calls out ::ffff/96 as a special IPv4 range; take a look - it is more complicated PTR queries partially handled locally, if in your default local zone; please comment/object if you have an issue with this DNSSEC handling if DNS64 is validating, SHOULD set AD=1 after successful validation. Potentially related to DNS "lies" or redirection controversy. Please voice any objections. ---------------------------------------------------------------------------- DNS64 Implementation Report Simon Perreault Viagenie ecdysis open source NAT64 gateway Standalone Perl, patch for Unbound and patch for Bind Source available Implementations respond differently, although all (we believe) follow the specs Andrew Sullivan: stupid clients break if there is an A record in the Answer section. Potentially some clients could be surprised and might break Bind keeps A recs in the answer section; what about authority section? Marcelo: "all other present recs MUST be left untouched" Simon: but isn't adding OK? DNS64 synthesizes records Mark Andrews: did this in Bind as an exercise - take the A response and modify the answer section - there is no SOA Simon: how to merge the A and AAAA responses Mark: if no AAAA response, but A, then you need to translate the A answer Authority section for PTR Draft says not to translate the Authority section for PTR - is this a good idea? Mark: you know what name space you're in, this is not hard, no reason not to. Andrew: current draft says not to, if you get a reverse tree query for a range that you do synthesis for, you answer - you are authoritative. But you lose the ability to look up for the original A record. Reverse tree is already pretty much broken Xing: separate problems for LIR and WKP Andrew: only do this for things for which you are answering Mark: synthesize a CNAME and let the rest of DNS processing work Merging, generating, pruning Which "additional section" does the draft mean? Should be more precise of what records to use, how to merge, etc. http://ecdysis.viagenie.ca ---------------------------------------------------------------------------- IPv4-IPv6 Translation FTP Considerations Iljitsch van Beijnum http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-04 Making FTP work in IPv6-IPv4 translation IPv6 client, IPv4 server, no assumption about network public/private, no assumption about statefullness. RFC 959 (1985) - either Passive mode (PASV) or Active mode (PORT) v4 address+port RFC 2428 (1998) - extended Passive (EPSV) only a port is required If all clients and servers use EPSV, no problem in translation About 28% of IPv4 FTP servers respond "command not implemented" Windows command line does not implement EPSV Possible solutions 1. get all servers to support EPSV 2. update clients to fall back to PASV after EPSV fails/times out 3. implement ALG in translator draft mandates 1 and 2, just describes 3. ALG EPSV->PASV is easy, EPRT->PORT is harder in stateful translator Don't try to do three-way FTP Go into transparent mode after AUTH Is this compatible with the current translation specs? Requesting Michael Abramson: control connections to two servers - arrange a transfer between. If the data connection doesn't match control connection. Iljitsch: that is what I call 3 way. We want to be dumb and not break stuff. Not worth the trouble it causes. Michael: add some clarification to the draft that this is not handled. Dave: proposed charter includes an FTP ALG for November. Should we adopt this as WG draft 00? Consensus to do so. ---------------------------------------------------------------------------- Virtual IPv6 Connectivity for IPv4-only networks Christian Vogt http://tools.ietf.org/html/draft-vogt-durand-virtual-ip6-connectivity-02 Additional technique for the toolbox to ease transition Deployment on legacy IPv4 networks Impetus/incentive over time shifts from v6 adopters to legacy v4; early on the v4 side has no incentive to invest in interworking. At some point v6 deployment reaches critical mass, the impetus to invest by v4 legacy increases to interwork and reach new v6 customers Virtual v6 connectivity - substantial v6 deployment, v6 hosts reachable via native v6 Objectives 1. deployment on v4-only networks 2. no host changes 3. no new global v4 addresses Marcelo: no changes in the v6 host? Not a strict requirement, there is time to spec this as a future requirement. May be optimization if the v6 host cooperates Four components: 1. virtual v6 addresses externally represent v4 host 2. virtual v4 addresses internally for v6 peers (no need to be global, but is dynamic and stateful) 3. IP protocol translators 4. mapping support in recursive DNS servers (passed on to translator) Gregory Lebovitz: who does the mapping? DNS server or translator? Christian: either could, but it makes sense to do it in the translator because it needs the mapping; Shin: if the session doesn't use DNS? Note well - Google cache would not work with this. Sometimes doesn't use DNS Jabber: how does this differ from NAT-PT? Christian: the DNS server was a bump-in-the-wire, breaking the DNS security model. The mapping in the recursive DNS server, security terminates in the recursive server, not e2e DNSsec. Gregory: the recursive DNS server could be collocated with the translator, logical distinction of functions. Key thing is the termination Marcelo: in this model the v4 host explicitly configures the DNS server rather than the BITW grabbing them Mixture of stateless/stateful mappings Challenges - no reverse DNS support for virtual address; virtual v4 address exhaustion; no e2e DNSSEC support for v4 hosts. Fred Templin: v4 initiated stateless mapping timing issue, long time between DNS resolution ---------------------------------------------------------------------------- Framework for IPv4/IPv6 Multicast Translation Stig Venaas http://tools.ietf.org/html/draft-venaas-behave-v4v6mc-framework-00 Companion to the Baker et al. Framework for Translation. Considered the 6 scenarios for Multicast A receiving from B == A to B e.g. Scenario 1 - IPv6 network receiving from IPv4 internet R wants to receive G, joins Translated(G). How does R know T(G)? Scenario 3 - cannot use simple embedding and stateless translation. May need new signaling mechanisms Dave: SDP allows a DNS name as group address; can use DNS64 Stig: any interest Xing: in IVI have some prototyping of multicast; Dave: please more discussion on list; not currently a milestone, premature to adopt as WG draft. ---------------------------------------------------------------------------- Common Functions of a Large Scale NAT Shin Miyakawa http://tools.ietf.org/html/draft-nishitani-cgn-02 How to structure the WG and Softwires drafts This is proposed as the framework for large scale NAT DS-lite includes LSN Should comply with NAT behavior RFCs, 4787, 5382 and 5508 Should limit number of ports to provide fairness LSN should log translation (for audit) LSN pass-through Redundancy - merge with other drafts on redundancy Please help with editing Marcelo: motivation good; LSN will have some constraints, like global IPv4. Identify the hard requirements, and what is the behavior when you ignore some requirements, or fallback. Provide more specific guidance. Dave: how much of this applies to "scale" versus architecture (multiple customers requiring fairness) if it is primarily fairness, also applies to CPE, hotspots, hotels, etc. Shin: aiming at ISP last mile; 1000 users Stuart Cheshire: NAT should be on the right boundary Shin: program exceptions ?: please detail the forwarding design, add a router box to diagram Matt: does the draft address geolocation for IP addresses? Content providers may rely upon this. Currently not. ------------------------------------------------------------------------------ Redundancy and Load Balancing for Stateful NAT Xiaohu Xu http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-00 DISR: no interest at this time Dean Cheng Stateful NAT including 46, 44 and 64 cases - generalized from initial draft on 64 translation; examples still based on 64 Cold standby - session establishment goes through primary; on failover the external realm address (source address) will change; to the internal host this is transparent Marcelo: TCP connection dies - new session intiated. Dean: the initiator has to do a TCP restart Marcelo: no coordination necessary Hot standby: keep the established sessions intact; automatic rerouting of traffic to standby NAT. The NATs must synchronize their mapping databases so they both assign the same external address and external port to an internal host. ?: can cold/hot standby be mixed? Dean: one or the other, deployment choice Chris Morrow: how does this differ from v4 NAT? well-known IPv4 NAT/firewall problem. Is this just a scaling issue? Dean: new problem in provider network Chris: cost for state, cost for coordination. But this is a solved problem in v4 NAT. e.g. Deloitte. Marcelo: is there a standardized method? Is there value in standardizing it? Dave: jabber comments that could be done without standardizing Christian: generalize, broaden the draft. Language is NAT64 oriented, but other scenarios can be handled with appropriate changes Load balancing is another feature ------------------------------------------------------------------------------ Reliable/scalable NAT mechanism based on BGP Chen Gang http://tools.ietf.org/html/draft-chen-behave-rsnat-01 ------------------------------------------------------------------------------ Generic Referral Object for Internet Entities Joel Halpern http://tools.ietf.org/html/draft-carpenter-behave-referral-object-00 Trial balloon - is this useful/interesting work? Should this be continued? Different parties need to pass references to each other IP addresses don't just work DNS doesn't always work - split DNS, hidden names, etc. Flexibility of referral form - IPv4, IPv6, domain name, new ways of referring to things. Define a standardized abstraction - generic referral object (GRO) Need named scope - link-local but local to what link? Multiple references are necessary - for multiple contexts. The referrer can only send what it knows. The sender can't know what will work for the receiver, it should send all scopes it knows. Two-tier TLV structure. Base Reference and qualifiers (e.g. type of scope and name of scope) Alain: how do you know the context of the receiver? Is it appropriate to send everything you know? Security model? Joel: need a way of naming scopes, referrer passes to the receiver. Security is not specified at this level Brian Ford: two orthogonal problems: defining format for generic reference - defining how to name scopes. Isn't URI a "global" reference framework Joel: almost Alain: naming scopes, how do you know you are in the same scope ------------------------------------------------------------------------------ NAT Control Protocols Review Wojciech Dec http://tools.ietf.org/html/draft-brockners-nat-control-protocols-review-00