BEHAVE Working Group Minutes, IETF 76, Hiroshima, November 2009 Chairs: Dave Thaler , Dan Wing minutes by Ed Jankiewicz SESSION ONE WEDNESDAY, 09:00-11:30, Orchid Centre ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch7-wed-am.mp3 at 11:42 ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch7-wed-am2.mp3 9:00 Note takers, agenda, existing milestones (Chairs, 10) Note well, notes, jabber, administrivia, agenda Doc status STUN family of docs (Dan W)- sctpnat splitting to TSVWG/Behave 6/4 translation docs not being presented today (Dave T) Van-beijnum-behave-ftp64 adopted as WG item Set target Gang Chen – should consider defining the problem before adopting ftp64 Dave T – take a hum – not unanimous but favor Gang – some of the objections are not represented here Dave T – neither is the author Marcelo – didn’t we settle this? The argument seems to be against the author, not technical Dan W – objections on list have not been technical Gang – fundamental issue whether we are redefining FTP Dave T – no charter to change FTP client or server, addressing translation; some statements in the draft may be out of scope. The WG should work out; this is about the behavior of an FTP ALG. Bo Zhou – draft says that ALG can be avoided Dave T – we have charter item to work on a doc on FTP64 ALG Magnus – the doc is under the WG control, consensus of the WG, the editor should follow this direction. Take up on the list. Dave T – maybe take up at an interim meeting with a presentation on content Intermediate meetings – webex, nearly done with the 1st priority items; expand scope of interim meetings? January and monthly – on the remaining scenarios WGLC coming up on 5 docs, need 5 positive reviewers on each; be active Call for hands; Dan notes – please read all docs, important that all are reviewed as a set for consistency and non-redundancy of normative text Marcelo – need some Behave expert review too Simon Perreault – I find no conflicts 9:10 Address Format (Xing Li & Marcelo Bagnulo, 30) draft-ietf-behave-address-format-01 Xing Li Objective – how individual IPv6 address translated and vice versa Mostly translation scope, but in Softwire discussed that it also covers encapsulation “IPv4-translatable” for stateless translation, for IPv6 hosts “IPv4-converted” for both state/less to represent IPv4 hosts; previous terms IPv4-mapped and IPv4-embedded were dropped Recommendations – don’t use WKP to construct IPv4-translatable, would cause IPv4 routing tables to be imported; MUST NOT be used for non-global IPv4 address Use 1/256 of IPv6 address space for translation, to conserve space U-bit MUST be set to zero; MUST NOT use subnet-router anycast; Stateless supports multiple translators Address format defined for prefix from /32 to /96 Containing octet of u-bit (U-octet) should be zero; the IPv4 address may span the U- octet; with /96 there is no suffix room Choosing prefix for stateless: should use same prefix for converted and translatable Prefix length recommendation related to each scenario Suffix – see appendix, need feedback from WG; NULL, neutrality checksum, encoding port range Marcelo – null works except for /32 (conflicts with subnet router anycast) Xing – details discuss offline Open questions – allow other prefix lengths? Marcelo – input from WG; both xlate and encap was supported Turn over to Marcelo for Stateful translation Textual representation – only if the last 32 bits, can be in decimal notation. This is only for display purposes Dave T – both input and output edits are concern. Don’t underestimate the value of ease of i/o for debugging etc. Simon Perreault – don’t change IPv6, don’t leave special code Dan Wing – new code will be needed either way; for entry minor advantage, this is not a big deal Brian Carpenter – ops community already has trouble dealing with folks who can’t understand letters in addresses. Dave T – whether this is only for xlate or encap too, address-to-string may need to understand the prefixes to get the output format right. Input is fine with no changes Marcelo – having it in the last 32 bits would be useful to some people, and minimizes changes. Dan – not the sole consideration; uRPF is another good effect; Stateful prefix choices: Either NSP or WKP, except WKP MUST NOT be used for scenario 3 (IPv6 internet to IPv4 network) How to choose a WKP? Either /32 or /96 In experimentation, ::FFFF:0:0/96 does not work with current implementations With a /32, IPv4 embedded in the other 32 bits, routing on the embedded IPv4. the same IPv6 host could be presented with different IPv4 addresses with multiple translators; need to update RFC 4281 to get decimal notation /96 – more difficult to route on IPv4, but is this a bad thing anyway? WG input Intermediate - /32 with two algorithms WKP::a.b.c.d or WKP:a.b.c.d:: Erik Kline – could embed twice Dan – what if the two embeds disagree? Spoof Dave T – keep it simple, minimize the number of possibilities. Between the other two options, lean towards /96; NAT-PT uses /96; if this is only for stateless, makes sense to stick with that, unless that has caused operational problems for users of NAT-PT Marcelo – NAT64 already supports the other format Dave – only the default WKP, unmanaged, no reason to do anything more complicated Hui - /96 might be avoided, we prefer shorter. We want to stuff other bits in the middle, e.g. load balancing Marcelo – two conflicting comments Alain Durand – keep it simple; /96 Chris Metz – keep this simple, no multiple algorithms; either /32 or /96 Dave T – for WKP request /32. request /96. defining two algorithms No hums on the last one; 3:1 for /96 over /32 IPv6/IPv4 Translation draft-ietf-behave-v6v4-xlate-03 Xing Li Same terminology In stateless xlate, how to handle ICMP and DF How does this differ from SIIT for MTU and fragmentation Should we define the translator as a router Simon – absolutely NOT a normal router; just specify the behavior Marcelo – recv Packet Too Big it BEHAVES like a router Can the translator adjust TCP MSS? Alain Durand – in Softwires we looked at this; feedback from transport people was strongly negative – things would break. We decided not to fight; don’t spec this, it will be an uphill battle. Dan – all vendors find it useful and valuable to adjust TCP MSS, may be a good idea to explain why Dave – it’s just a NAT thing With DF=0, SIIT would fragment; improving this would introduce state. Should be keep this behavior? Mailing list said Yes Non-standard implementations (violate 2460 section 5) with respect to minimum MTU and ICMP “too big”; some routers still fragment even with DF=1 Marcelo – if the host is willing, but the admin filters ICMP, and configures only 1280 packets workaround Marcelo – non-zero identifier Alain Durand – trying to spec a fix to nodes that didn’t read the previous spec. Marcelo – host implements the spec, but we break the 1280 minimal assumption because of the embedding of IPv4. Alain – this assumption is encoded in many places Fred Templin – even if you send 1280, you may get an ICMP too big back. The host should then send DF Alain – fundamental broken in the translator if it breaks the 1280 assumption Remi Despres – if you send IPv6 packets smaller than 1280 and get back a packet too big, switch to IPv4 Marcelo – host is not receiving packet too big Dave – two choices: should we design translators to accommodate the possibility that hosts do not receive ICMP too big messages; Suresh - Alain – this is fundamentally wrong Dan – do we want to account for packet too big being filtered on the network? Marcelo – no, this is defined in IPv6 spec, even if the packet was less than 1280, retransmit with DF=0 Dan – repeated the question, hum – definitively more for NOT handling Some routers fragment even with DF=1; example 5 in appendix, proposed behavior Alain – the v4 path could be considered “the link” so frag/reassembly should be ok Dave T – TTL behavior… This question seems to be related to the previous decision on packet too big, so don’t change RFC 4884, 4950 and draft on ICMP extensions Follow RFC 5508; translate what is in RFC 4884, pass unknown extensions as bit strings. Is this ok? Marcelo – do we know what we are doing? Breaks the unnumbered draft Magnus – right choice not to translate; pass along. Fine to not translate. Dan – any objections to this proposal? None at the moment Summary of SIIT differences Stateful IPv6/IPv4 Translation draft-ietf-behave-v6v4-xlate-stateful-02 Marcelo Look at decisions made for stateless case; some are common, should we behave the same way? Others are specific to the stateful or stateless case only. e.g. should we simply use 1280 and avoid PMTU discover, as we just decided for stateless? So far comments lean to common behavior Simon – why not MAY? Marcelo – we need to specify behavior if it is allowed anyway Fred Templin – when IPv4 sends DF=0, expects fragmentation anyway, so let it fragment Remi Despres – with DF=0 should it never receive packet too big? In IPv4 a lot of hosts do not do PMTU discovery; as far as I know, the router should fragment rather than send packet too big fragments other than first do not have the TCP/UDP header; Opt 1 – accumulate and reassemble; process when fully received; requires memory, and can be DoS vector Opt 2 – keep state (ID value); if packets other than first arrive, may need to store until it arrives (if ID not found in table) Don’t need to store if packets arrive in order; should require less memory. More complex, still attack vectors What to do? Brian Carpenter – implementation issue – we should specify the external behavior Marcelo – good point, but in other cases we are specifying how to do things Simon – you have to reassemble for UDP chksum 0 anyway, need to store UDP fragments other than first Xing – stateless draft does not consider chksum=0 Marcelo – we are not dealing with it Simon – drop it? Yes Fred Templin – deeper analysis is necessary, rather than a poll. Marcelo – discuss on the mailing list, but otherwise we need to decide and move on. Dan – interim meetings Suresh – worst case scenario here is the other scenario ? – not a mandatory behavior; Marcelo – need to provide guidance, how to handle; tiny fragment attack (overlapping fragments) complex threats Dave T – may need to call an interim in December to address this; try to discuss on the list, and then join the interim. Table to that Simon – premature optimization is the root of all evil; punt and stick to the first option, which is safe. Optimize later Magnus – is it a general question on fragmentation, or between the specific options? What to do with IPv6 with no fragment header? Same as stateless? Fred Baker – yes, be consistent. And specify what we want to happen 10:05 DNS64 (Marcelo Bagnulo / Andrew Sullivan) draft-ietf-behave-dns64-02 Andrew Sullivan on WebEx Proposal on the list to change the text, comment from Brian Carpenter Need to address multiple interfaces problem; may have multiple connections to multiple networks with DNS64; can DNS64 answers be used globally on all interfaces. Need a decision on the proposed text to advance this doc Dave T – please comment on the list Marcelo – to move to WGLC, we should settle the address format, this doc depends on it 10:25 DNS46 for Stateless Translator draft-xli-behave-dns46-for-stateless-00 Xing Li Generally, DNS46 was considered harmful (NAT-PT deprecated) We need a doc to specify how it will work, stateless translation needs it Scenario 2 – IPv4 Internet to IPv6 Network Xlate and DNS mapping functions are decoupled DNS64 defined for stateful can be used here DNS46 behavior needs to be documented; in some cases responses are synthesized For Scenario 6 IPv4 net to IPv6 net, can use DNS resolver to do the translation Not discussed – DNSSEC or Reverse DNS Marcelo – clarify, three ways of handling, like in DNS64. translating in DNS resolver is the last resort; go to v6ops to get their reaction; PNAT: Requirements and Motivations (Feng Cao, Hui Deng, 15) draft-cao-behave-hbt-req-00 draft-huang-behave-rfc2767bis-00 draft-huang-behave-rfc3338bis-00 draft-huang-behave-pnat-00 Hui Deng Several host to host scenarios Investigate current requirements on host-based translation Some mobile operator requirements R1 – legacy IPv4 apps, not IPv6 aware; long tail R2 – IPv6 only networks; reduce cost factor R3 – minimize overhead on wireless links R4 – decentralized h2h, avoid centralized relay Gap analysis of current solutions; each has one or more deficiency PNAT covers all 4 Sri Gundavelli – missing some items, like whether approach requires change to host stack, ?, h2h GW-init-DS-lite does not have an issue Simon P – for peer to peer need DNS; right now p2p does not use DNS Making it use DNS would be easier than IPv6; people may not easily update applications Alain – looked at PNAT about a year ago, NAT464. Problem is real, may not be the right solution. Double translation doubles the chances for distortion. The emitted packet differs from the input. E.g. ALGs handling embedded addresses. In Softwires, encap over IPv6 transport seemed a safer, better solution. Important to solve, but a better way to solve. Go to the Softwires working group to extend DS-lite to meet the gap. Make sure the encap meets your need. Lots of benefits to the application perspective, nothing to do. Minimal code to encap, tunnel IP in IP. Double translation; two scenarios, one is more suited for translation, the other may be more suited to encap Xing Li – DIVI can support h2h direct Jari Arkko – what is the priority of all these scenarios, no need to do a perfect job, but get bang for the buck. 3GPP most networks support IPv6 and dual stacking. Content providers offering IPv6. moving to significant IPv6 usage. You mentioned IPv6 only as a goal, may need to run two networks due to the need to run PNAT, the benefit may go away Tina Tsou – IPv4 services on an IPv6 network; we have implemented PNAT Basavaraj Patil – DSMIPv6 also offers some capabilities, answer yes Sri – DSMIPv6 is not exactly a step towards migration Raj – DSMIPv6 satisfies virtually all the scenarios Sri – not sufficient – take offline Dave – is this a good set of requirements? Not really looking at solutions yet. Haven’t heard any argument against the 4 requirements, nor against the scenarios. Heard comments on priorities, some additional requirements, some suggested other columns to consider like DSMIPv6, and challenges to some of the cells on the gap analysis. And comments on whether better to start with existing solutions and move no to yes, etc. Charlie P – works without modification to v4/v6 hosts should be a feature; would be more unbiased if not called “gap analysis”; I have a solution draft that would be responsive too. 11:05 PNAT Discussion (all, 15) Dave T – two questions for the group, teed up for the interim meeting 1. Should the framework document add a definition of “host based translation” 2. Should behave recharter to address issues in host-based translation? Marcelo – on the first question, need to wrap up what we have. Don’t keep creeping in new ideas, scenarios. Maybe framework is a special case, but in general, close and move forward. We focused on priorities, we don’t have the energy to tackle everything at once. Still need to focus on the next most important Alain – sympathy for Marcelo’s comment to stay focused. Don’t retread discussions already held in Softwires, work together, divide and conquer Xing Li – close docs and submit; current framework covers this – IVI in home gateway Sheng Jiang – don’t stop working on it, while focusing on the priorities. Gang Chen – further discuss on interim meeting Bo Zhou – why close the framework when there are still things to discuss? Marcelo – we have reached some conclusion, but there are always new use cases. This is the first phase of work, close and move forward. After published, extension or update is ok. Tony Hain – in general agree to close down, but this scenario seems to be something that should be included in the translation framework. Other solutions may be in Softwires, but the problem should be well defined in the framework Magnus – finish initial scenarios by the end of the year, if we open the doc again it will create more delay. No problem revisiting the framework after publication. ============================================================== ============================================================== ============================================================== SESSION TWO FRIDAY, 09:00-11:30, Orchid Centre audio archive: ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch7-fri-am.mp3 at 20:50 Agenda, note takers (Chairs, 5) Learning the IPv6 Prefixes of an IPv6/IPv4 Translator (Dan Wing, 15) draft-wing-behave-learn-prefix-04 how to learn the prefix of an IPv6 Translator several scenarios, applications with IPv4 literals to find out that there is a translator Mechanisms – RA mechanism is removed, not standardized yet; DNS NAPTR or new DHCPv6 option Not sure what to do with these two ideas – DNS can be used on all OS and applications, but DHCPv6 is not supported in all OS or do not allow application to use new option. This makes DHCP a little problematic Dave T – general question, DNS is significantly more complex, DHCPv6 for addresses and stateless variation; some implementations need to change, but which one is simpler to do for an implementation? Not all of DHCPv6 – only need INFORM exchange, nothing else Remi – second, DHCP seems appropriate; option 3? Dan – only an experimental draft, no spec on how to do DHCP INFORM in RA; Remi – great idea Dan – Ralph Droms agrees, no one has written a spec Eric Vincke – prefer DNS because applications can’t use arbitrary port to do DHCP inform Dave T – think DHCP Inform can be done on any port; on an OS without DHCPv6, two applications might bind to the same port – yes, there are port sharing issues, but not in conflict with DHCPv6 Dave T chair – do we have enough information to have an opinion? Does the WG need more information? Seemed louder for the first one. Dan – below the threshold Marcelo – yes we need this to make network specific prefix work Dan – helpful for WKP too Marcelo – absolutely needed for NSP Dan – does anyone really care? Marcelo – I do Dave – not enough readers Brian – no doubt requirement; no basis to decide between the two options, some clients can more easily use one or the other, leaves no choice but both right now Marcelo – more important to have solution rather than choosing exactly one; no clear argument on one or the other, either pick one or explore both further Remi – not necessary that both client and server do both, if the server does both, the client can do either Dave – problem worth solving, which solution needs further study Issues with IP Address Sharing (Matthew Ford, 15) draft-ford-shared-addressing-issues-01 Mat Ford SHARA BOF in San Fran, in SW and Intarea Collect all the issues across all address sharing approaches; catalog and analysis of the issues, not comparison of approaches or solution specifics CGN-based (private address sharing) vs Port-Range solutions (public address sharing, avoid CGN) Long tail of subs requiring more than median number of ports; ISP need to balance sub/addr ration, port churn Various areas that raise issues in address sharing Impacts on applications, breaks things ALGs to enable applications with NAT, subs limited to what the CGN supports; port range solutions may require mods to ALGs ICMP – inbound ICMP sourced offnet will break; on-net may be unroutable without special handling Multicast and Mobile IP could use some expert input Discussion of single-point failure issues Eric Vyncke – path MTU discovery – off-net host keep cache per IP address, Dan Wing – scary, I can make a server believe everyone has an itty bitty MTU; talks about what content providers should do, and what end-user devices should do – should this be split out into the right areas, or one draft to cover both Mat – issues for the deployer, and those it creates for third parties – revising to break those out Bob Hinden – if you are sharing addresses, IP address based attacks are multiplied Remi Despres – need a comprehensive view of AplusP solutions; dynamic vs static AplusP, mesh, more analysis of solutions Geo-proximity and geo-location issues created for third parties; shared addresses reduce confidence and location granularity; Traceability – requirements for storing mappings Collected some additional issues through this week, including here Hope to have a comprehensive reference for solution developers Address-sharing stateless double IVI (Xing Li, 20) draft-xli-behave-divi-00 add a second stateless gateway stateless 1:1 IVI cannot use IPv4 address effectively stateless 1:N IVI can share IPv4 address stateless 1:N dIVI scenario 1, 2, 5 and 6 no port multiplexing when going v6-v6 basic features of IVI, IPv4 public address shared by N IPv6 hosts port number range for each host is predefined, encoded into an IPv4-translatable address simple modulus algorithm to translate addresses; allocate ports deterministically two types of IPv6 addresses IPv4-converted address – no change IPv4-translated address – use 16 bits to represent the port range/index; 4 bits for ratio, 12 bits for the host index, up to 4096 hosts (each gets 16 ports) Add a function in the home gateway to xlate, same as stateless 1:1 IVI, either stateless or port number mapping. Also allows IPv6 cut-through Port number mapping, different rules for Well known port, etc. Home gateway or end-system (host gateway) implementations possible Linux prototype available No change to the IP model, with gateway no change to end system and application; NAT traversal techniques can be used Uli – how do you do autoconfiguration? Xing – you must do stateless DHCP Alain Durand – PNAT; very much like NAT464, double translation is not a change to the IP model – multiple interfaces with different hosts. Number of problems, similar solution in other working group Dan – different than PNAT – lossless translation, to the degree that it is much like tunneling. Using address mapping to do an efficient tunneling. Alain – competition is not a good idea; similar work in Softwires Dan – AplusP – need to analyze the relationship with that approach and issues brought up there; find the right place to do this Remi – this is one of the AplusP variants; one difference translation versus encapsulation using the same address mapping? Dan – that analysis needs to be done. NAT Security (Fernando Gont, 15) draft-gont-behave-nat-security-03 recommendation for secure protocols for NAT revision since IETF 73, restructured, edits recommendations encoded as specific requirements REQ-1: advice on dealing with DoS, well-known fragmentation attack REQ-2: port reservation, local use on NAT REQ-3: p2p proper authentication, already defined in another draft, may change to an informational reference REQ-4: traversal by security protocols, e.g. port 443, no ALG for IKE IP identification – if non-unique can lead to corrupted packets; REQ-5: the NAT MUST ensure uniqueness, not reuse REQ-6: MAY rewrite the TCP sequence number, having a NAT may create a new interoperability problem; should also rewrite ACK number; Initial Sequence Number should be unpredictable REQ-7: similarly for TCP timestate Fernando – please read, comment Dave – consider the WG poked Optimal Load-balance mechanism for NAT64 (OL-NAT) (Chen Gang, 10) draft-chen-behave-olnat-00 Gang Chen New draft Problem statement – Large-scale network, growth – NAT64 is single-point of failure; Routing distance metrics may lead to unbalanced load distribution, overload that NAT64 Static configurations or synchronize mappings How to overcome – extended anycast load-balancing; discover optimum NAT64 box New metric for “optimal” NAT64, new ICMP to sync mapping Mapping sync – include server load info, create a virtual group with specific anycast and multicast address Eric Vyncke – hop by hop? Routers do not like, host MUST send with TTL of 255 Feedback, comments requested Tony Hain – optimizing NAT64 seems like a bad idea, we might want to discourage its long term use, but we need something in this space. Assuming the host needs to determine this, rather than just trying to send packets, with ICMP (reactively) redirecting the host. Brian Carpenter – worried that you haven’t proved that you need this, the other model of having lots of NAT64 distributed, localize any load or failure problems. Don’t understand how the mechanism to distribute the mappings is transactionally safe, consistent – in time and complete. Not explained sufficiently. ? – if we assign the unicast translator prefix, how does the host find the next one? NAT State Synchronization Using SCSP (Dean Cheng, 15) draft-xu-behave-nat-state-sync-00 multiple NATs with state synchronized use existing Server Cache Synchronization Protocol (RFC 2334) for distributed database link-state algorithm to flood reliably using SCSP among NAT devices in a redundancy group requirements: sync is a MUST for hot standby, load balancing; only stateful content MUST be replicated; NAT fails but NAT sessions MUST survive, no impact on traffic multiple NATs at the border form a redundancy group identified as a SCSP Server Group ID (SGID); one is primary, one or more backup; replacement primary elected this is for stateful NAT only Shin – like to have a relay instead Protocol ID indicates NAT type (NAT44, NAT64, etc.) Address fields may be IPv4 or IPv6, so a length field is encoded in the NAT specific and mandatory common Shin Miyakawa – only primary NAT can create new cache – sometimes you want multiple NAT Dean – can result in inconsistent traffic flow Dave – primary may be different based on port ranges Dean – this is a very conservative choice Brian Carpenter – agree this superficially looks like a reasonable approach to synch; first time SCSP has been heard from since 1999. what is the implementation experience with SCSP? If none, not a good base. NAT444 Definition (Ikuhei Yamagata, 10) draft-shirasaki-nat444-00 Shen Miyakawa Proposing to define a structured relationship between I-Ds about IPv4 Address sharing schemes Let the work sort up – common requirements factored out from each solution draft NAT444 could concentrate on only the details Coordinate with work in other working groups NAT444 parallel with IPv6 in the network NAT444 operated by cable networks commercially, no need to replace CPE Most conservative approach to keeping legacy systems working Ready to ship to ISP market – we should have sound and concrete RFCs related to it Mat Ford – some of draft-shrasaki could be pulled into shared-addressing-issue Shin – yes, common issues, but keep NAT444 specifics in NAT444 Dave T – discussion among WG chairs to see where this work should be done Multicast IPv6/IPv4 Translation Framework (Stig Venaas, 15) draft-venaas-behave-v4v6mc-framework-01 Stig Venaas Update, minor changes on draft; new co-authors, new text How easy is it to use DNS for multicast? Often use literal addresses; SDP is the most common method, most often a literal address, could be a domain name, but need to know IPv4/IPv6 statically in SDP Need an IP-neutral SDP? Or ALG that re-writes? FTP or e-mail transport, so not that easy. More work and things to add with new authors Bob Hinden – in IPv6 design there was a conscious decision to not make multicast translation easy; don’t know if we need to go here. Dave T (as individual) – still need a way to coordinate the ends Dan Wing – how many are interested? A few hands (including me) Payload-assisted Delivery for SIPNAT (Charles Perkins, 10) draft-perkins-behave-dpinat-00 pitfalls lead to “always on” NAT for v4->v6 translation source IP NAT – bidirectional, no changes to hosts, not requiring dual-stack or tunneling, delegation; relies on DNS so IPv4 internet host can find the IPv6 service Instead of using port number use the address itself, more like existing NATs Failure modes – one source to two destinations; too many new flow requests at the same time Is this really like flow management? This should work at speed Payload assist for higher scalability, robustness http.host in http GET is a good help to disambiguate additional techniques to handle other apps aware customers could get assured delivery Cedric Westphal – Queueing Theoretic analysis of this submitted to ICC 2010; IPv6 will grow faster if it assures access from IPv4 Please read, comment HTTP 4/6 Relay (Dan Wing, 10) draft-wing-behave-http-46-relay-02 instead of using translation, maybe there is a simpler way using HTTP relay and proxy. dynDNS – WebHop – variable IP address, they will transparently proxy your ugly domain name HTTP relay – terminating and reoriginating; incoming IPv6 come from the relay HTTP redirect – use client’s “Host” header Dancing turtle over IPv4 network Richard Barnes – not a bad idea, bang for buck, not a complete solution; not significantly different from standard HTTP proxy Dave announced: Next Interim: Dec 16, 7:00am US Pacific Time