Subject: Re: [pcp] UNSUPP_FAMILY error code

From: <[email-masked]>
Date: Wed, 5 Jun 2013 11:17:46 +0200

Stuart,

I'm objecting your proposal because I don't want to add a new failure case to the list we already have. 

There is a risk that some PCP clients won't try all AFs for the same PCP server and therefore the host won't be able to receive incoming packets via that PCP-controlled device. Consider an IPv6-only client behind a NAT64. If the pcp client asks for IPv6 external address, the server will reject it with the error you are proposing. If the pcp client does not try another AF, the IPv6-only host cannot receive incoming sessions from an IPv4-only host.

An application does not care about the AF of the remote machine; what it should care about is how to maximize the chance to place successful session with hosts wanting to do so. 

A PCP server that assigns only addresses of only one AF should return an address of the AF it manages. It is up to the client to decide to make use of it or not.

If the PCP server manages several AFs, the PCP server will make it best to accommodate the suggested AF and if it cannot an alternate AF can be proposed to the client. Again, it is up to the client to decide whether it will make use of that address of not.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Stuart Cheshire
>Envoyé : jeudi 30 mai 2013 17:44
>À : [email-masked]
>Objet : Re: [pcp] UNSUPP_FAMILY error code
>
>On 30 May 2013, at 4:30 AM, [email-masked] wrote:
>
>> Unlike MAP4/MAP6, the server receiving a MAP request is not obliged to
>return an IP address following the indication included in the suggested
>external IP address field. It will try to best accommodate it, but if not,
>it would be fine if it returns another AF address; then it is up to the
>client to make use of it or not.
>>
>> In another words: we should not use Suggested IP Address as PREFER_AF
>option ;-)
>
>RFC 6887 states that the client uses the appropriate all-zeros address in
>the Suggested External Address field to control what family of external
>address it gets:
>
>   When operating a server (see Sections 10.1 and 10.2), the PCP client
>   knows if it wants an IPv4 listener, IPv6 listener, or both on the
>   Internet.  The PCP client also knows if it has an IPv4 address or
>   IPv6 address configured on one of its interfaces.  It takes the union
>   of this knowledge to decide to which of its PCP servers to send the
>   request (e.g., an IPv4 address or an IPv6 address), and whether to
>   send one or two MAP requests for each of its interfaces (e.g., if the
>   PCP client has only an IPv4 address but wants both IPv6 and IPv4
>   listeners, it sends a MAP request containing the all-zeros IPv6
>   address in the Suggested External Address field, and sends a second
>   MAP request containing the all-zeros IPv4 address in the Suggested
>   External Address field).  If the PCP client has both an IPv4 and IPv6
>   address, and only wants an IPv4 listener, it sends one MAP request
>   from its IPv4 address (if the PCP server supports NAT44 or IPv4
>   firewall) or one MAP request from its IPv6 address (if the PCP server
>   supports NAT64).  The PCP client can simply request the desired
>   mapping to determine if the PCP server supports the desired mapping.
>
>and
>
>   the application constructs a PCP message with the MAP Opcode, with
>   the external address set to the appropriate all-zeros address,
>   depending on whether it wants a public IPv4 or IPv6 address.
>
>We really need WG consensus on whether the external address family is a
>firm requirement or merely a hint, so client writers know what to expect.
>
>I don't see any benefit in requiring client writers to handle the client
>unexpectedly getting an address family it doesn't want.
>
>That's also a code path that's likely to be poorly tested. I can imagine
>lots of IPv4-only devices being tested with IPv4-only NATs and shipped
>today, and then, a couple of years from now, crashing the first time they
>unexpectedly get handed an IPv6 address.
>
>We'll be shooting ourselves in the foot if we choose that path.
>
>Stuart Cheshire
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 06 Jun 2013 16:37:45 -0700

> There is a risk that some PCP clients won't try all AFs for the same PCP server and therefore the host won't be able to receive incoming packets via that PCP-controlled device. Consider an IPv6-onl…

If the client writer had thought about IPv6, then the client would ask for an IPv6 external address. If the client does not, chances are the client writer never thought about that, and the code will likely fail (or even crash) when given an IPv6 external address.

If we allow what you want, the PCP adoption road map goes like this:

Early PCP servers only support IPv4.

Early PCP clients only support IPv4.

In fact, some early PCP clients mistakenly pass the IPv6 all zeroes address, and the early PCP servers give them back an IPv4 external address anyway, which the client then puts in a DNS IPv4 address record. So it all works, but largely though good luck.

Now, with this ecosystem in place, a vendor wants to introduce a gateway that supports IPv6. Hooray! We all want that. But this gateway returns an IPv6 external address, and a whole bunch of existing clients crash or otherwise fail in response to that. Management says the company can't ship a gateway that breaks existing clients.

So the path you propose leads to a dead end where PCP can never add support for IPv6, because of buggy clients that were allowed to exist by overly-lenient early implementations.

Stuart Cheshire

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 08:47:55 +0200

Stuart,

I'm re-iterating below what I'm suggesting:

* The PCP client can indicate a *** preferred *** AF in the Suggested External IP Address.
* The PCP client MUST be prepared to receive an address of a distinct AF than the one indicated in the request.
* The PCP server will try to honor the suggested AF, but it will always return an address belonging to the AF it supports (modulo port quota checks). 
* It is up to the PCP client to make use of the address returned by the PCP server or not.
* If the PCP client has no indication about the capabilities of the server, the PCP client may try two requests each one with a # suggested AF.

Instead of returning an error, an offer is made to the client.
This behavior maximizes the chance to get an address and make use of it.

I fail to see how this mode will induce failures.

Cheers,
Med

>Envoyé : vendredi 7 juin 2013 01:38
>À : [email-masked]
>> There is a risk that some PCP clients won't try all AFs for the same PCP
>server and therefore the host won't be able to receive incoming packets via
>that PCP-controlled device. Consider an IPv6-only client behind a NAT64. If
>the pcp client asks for IPv6 external address, the server will reject it
>with the error you are proposing. If the pcp client does not try another
>AF, the IPv6-only host cannot receive incoming sessions from an IPv4-only
>host.
>
>If the client writer had thought about IPv6, then the client would ask for
>an IPv6 external address. If the client does not, chances are the client
>writer never thought about that, and the code will likely fail (or even
>crash) when given an IPv6 external address.
>
>In fact, some early PCP clients mistakenly pass the IPv6 all zeroes
>address, and the early PCP servers give them back an IPv4 external address
>anyway, which the client then puts in a DNS IPv4 address record. So it all
>works, but largely though good luck.
>
>Now, with this ecosystem in place, a vendor wants to introduce a gateway
>that supports IPv6. Hooray! We all want that. But this gateway returns an
>IPv6 external address, and a whole bunch of existing clients crash or
>otherwise fail in response to that. Management says the company can't ship
>a gateway that breaks existing clients.
>
>So the path you propose leads to a dead end where PCP can never add support
>for IPv6, because of buggy clients that were allowed to exist by overly-
>lenient early implementations.
>
>Stuart Cheshire
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 7 Jun 2013 14:06:06 -0700

> I fail to see how this mode will induce failures.

Because the PCP client library, or the application calling the PCP library, will have never exercised its code to handle receiving a different address family, because it was developed and deployed for years on an IPv4-only network at the developer's house or developer's company.  As an example, imagine in a decade we introduce a new address family called IPv8, and imagine failures would occur with a PCP client library or an application that only understood IPv4 and understood IPv6.

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 07 Jun 2013 15:25:29 -0700

> * The PCP client MUST be prepared to receive an address of a distinct AF than the one indicated in the request.

You can say MUST MUST MUST as much as you like, but that doesn't change reality. There will be buggy clients that don't handle this right, unless we prevent that by making the bug so obvious that they realise they can't ship before fixing it.

I have seen PCP clients that pass all-zeroes IPv6 as the suggested external address, but only handle IPv4 replies.

They do this because the PCP server they tested with ignores the suggested external address completely, and always returns an IPv4 external address.

Suppose that PCP client goes into a very widely deployed game console. Now, as a gateway vendor, you can *never* return an IPv6 external address, because if you do, the game console breaks, and customers will return your product for a refund and you go out of business.

To stop this outcome we need to make the buggy PCP client not work *now*, before it gets widely shipped.

Protocols ossify fast unless good design decisions are made early on.

Stuart Cheshire

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 08:31:54 +0200

Hi Dan,

Please see inline.
Cheers,
Med

>De : Dan Wing [mailto:[email-masked]]
>Envoyé : vendredi 7 juin 2013 23:06
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Stuart Cheshire; [email-masked]
>> * The PCP server will try to honor the suggested AF, but it will always
>return an address belonging to the AF it supports (modulo port quota
>checks).
>> * If the PCP client has no indication about the capabilities of the
>server, the PCP client may try two requests each one with a # suggested AF.
>>
>Because the PCP client library, or the application calling the PCP library,
>will have never exercised its code to handle receiving a different address
>family, because it was developed and deployed for years on an IPv4-only
>network at the developer's house or developer's company.

[Med] If an implementation does not follow the spec, then yes failures can be experienced. With the error code, things may be worse: a client may ask for a AF but the server returns an error. If the client doesn't ask for another AF, it will never get an external IP address. Not servicing the request and returning an error opens a new communication failure window. We already have many in PCP, IMO we should not add a new one. We should encourage implementations to be prepared to receive any AF from the server, not the one indicated in the Suggested External IP Address. 

  As an example,
>imagine in a decade we introduce a new address family called IPv8, 
[Med] IPv8 is already assigned since 1994. No need to wait for another dacade ;-)

and
>imagine failures would occur with a PCP client library or an application
>that only understood IPv4 and understood IPv6.
>
>-d
>
>
>>
>> Cheers,
>> Med
>>
>>

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 10 Jun 2013 19:12:03 -0700

On 9 Jun, 2013, at 23:31, [email-masked] wrote:

> [Med] If an implementation does not follow the spec, then yes failures can be experienced. With the error code, things may be worse: a client may ask for a AF but the server returns an error.

Yes. And the developer notices this failure, and fixes the bug before shipping the product.

Stuart Cheshire

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jun 2013 02:30:11 +0000

> Yes. And the developer notices this failure, and fixes the bug before shipping the product.

<ad hat off>
+1
</>

---

From: <[email-masked]>
Date: Tue, 11 Jun 2013 09:01:37 +0200

Hi Stuart, all,

The failure I'm talking about is the client failure to get an external IP address/port of any address family. 

By fixing the bug, do you mean the client (1) will be designed to always ask for another AF if UNSUP_AF error is received from the server or (2) by adjusting the zeroed Suggested External IP Address?

(1) is much more reliable since a mapping will be created if port quota is not reached.
(2) may solve the problem for a specific testing case but it does not ensure no failure will be experienced if you change the setup. How the pcp client knows the capabilities of the server to set the suggested AF accordingly? 

I tried to summarize this discussion in the following table:

+----------------------+-----------------------+--------------------+
| No Capability Discovery is supported                              |
+----------------------+-----------------------+--------------------+
|  Client's Behavior   |       UNSUPP_AF       |  Suggested AF is   |
|                      |                       |    only a hint     |
+----------------------+-----------------------+--------------------+
| The client sends one |     Failure may be    |  A mapping can be  |
|     request only     | experienced (i.e., no |      created       |
|                      |    mapping won't be   |                    |
|                      |  created if the AF is |                    |
|                      |     not adjusted)     |                    |
+----------------------+-----------------------+--------------------+
|   The client tries   |    A mapping can be   |        N/A         |
|  another AF only if  |        created        |                    |
| an error is received |                       |                    |
+----------------------+-----------------------+--------------------+
|  The client issues   |   One mapping and an  |  The same mapping  |
|  systematically two  |   error code will be  |  will be returned  |
|    requests with     |    returned if the    |   if the server    |
|     distinct AFs     |  server supports one  |  supports one AF.  |
|                      | AF. Two mappings will | Two mappings will  |
|                      |   be created if the   | be created if the  |
|                      |  server supports two  |  server supports   |
|                      |          AFs.         |      two AFs.      |
+----------------------+-----------------------+--------------------+

+----------------------+-----------------------+--------------------+
|  Capability Discovery is supported                                |
+----------------------+-----------------------+--------------------+
|  Client's Behavior   |       UNSUPP_AF       |  Suggested AF is   |
|                      |                       |    only a hint     |
+----------------------+-----------------------+--------------------+
| The client may issue |  One or two mappings  |     One or two     |
|  0, 1 or 2 requests  |   will be created if  |  mappings will be  |
|    to the server     |  the server supports  |   created if the   |
|  (according to the   |    two AFs. If the    |  server supports   |
|  capabilities of the |  capability discovery |      two AFs.      |
|     PCP server)      |     is reliable,      |                    |
|                      |   UNSUPP_AF won't be  |                    |
|                      |   used by the server  |                    |
+----------------------+-----------------------+--------------------+

We should focus more on the behavior of the PCP Client. 

Cheers,
Med

>Envoyé : mardi 11 juin 2013 04:12
>À : [email-masked]
>> [Med] If an implementation does not follow the spec, then yes failures
>can be experienced. With the error code, things may be worse: a client may
>ask for a AF but the server returns an error.
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Jun 2013 17:27:18 +0200

Mohamed,

I think Stuart is right on this issue. I'll try replying from my point 
of view:

The point is that all clients will know how to handle errors. It is 
required for basic funtionality.

Not all clients will know how to handle external addresses of a 
different AF than they asked for. It is highly unusual and will likely 
not be tested.

So if you have an ecosystem of clients that will crash when the PCP 
server returns an external addresses of a different AF than they asked 
for, why would you want the server to do that?

Remember that not everyone is in the situation of having control over 
the PCP server *and* the client. Server admins will be faced with an 
heterogeneous set of clients.

Simon

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 08:27:50 +0200

Simon,

What I'm arguing for is exactly what Stuart said in Slide 7 of his presentation available at: http://www.ietf.org/proceedings/80/slides/pcp-8.pdf!

The question is not whether we agree or not with the new proposed error code but how can we help a client to successfully create a mapping and what are the triggers for a client to adjust the suggested external IP address in the first request?

Given:
* the client is not aware of the AFs supported by a PCP server
* the client want to maximize its chance to establish communications with remote peers of distinct/various AFs, 
* the server uses the suggested external filed as a hint
* the server cannot reject a well-formed request (according to Stuart's principle)

Is it normal to return an error instead of serving the client?

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De la part de Simon
>Perreault
>Envoyé : mardi 11 juin 2013 17:27
>À : [email-masked]

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Jun 2013 23:59:41 -0700

> The failure I'm talking about is the client failure to get an external IP address/port of any address family.

Software cannot reason about an unexpected situation and decide on an appropriate course of action. Software can only execute behaviours that have been programmed by the software writer. And software writers don't program behaviours that they haven't thought of. If the software writer has never thought about the case of getting an IPv6 address back, then the software will not handle that. It can't work out for itself what to do when it happens. It's quite likely it will take the last four bytes of the IPv6 address and assume that's an IPv4 address, which will not work.

So the challenge is to make software writers aware of this.

If client software appears to "work", then it will get shipped.

If client software doesn't work, and the users or testers report, "There's a message in syslog about error 14," then the issue enters the software writer's consciousness, and they investigate why it's happening, and fix their software.

The longer we let client software writers remain blissfully unaware that they're inadvertently requesting an IPv6 address, the bigger problem we're creating for ourselves when gateways start honouring the client request and actually start returning IPv6 addresses.

Stuart Cheshire

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 10:31:38 +0200

Stuart,

We are approaching the problem with two different perspectives:
* You are more concerned about "poor" PCP client implementations
* I'm more concerned about how a client can get connectivity and how the server can help in maximizing the chance to honor a request

I understand your concern but defining a new error code will create a new connectivity failure case if the client does not try another request with the adjusted Suggested External IP Address. But what are the guarantees a "poor" implementation will try another adjusted request?

When I say a PCP should be prepared to receive any address AF in a response, this means a corresponding test case to assess the behavior of a PCP client should be envisaged. 

IMHO, we should focus on the origin of the problem: 
* How PCP can help a client to get connectivity?
* What are the triggers for a PCP client to adjust the Suggested External IP Address?

Cheers,
Med

>Envoyé : mercredi 12 juin 2013 09:00
>À : [email-masked]
>Software cannot reason about an unexpected situation and decide on an
>appropriate course of action. Software can only execute behaviours that
>have been programmed by the software writer. And software writers don't
>program behaviours that they haven't thought of. If the software writer has
>never thought about the case of getting an IPv6 address back, then the
>software will not handle that. It can't work out for itself what to do when
>it happens. It's quite likely it will take the last four bytes of the IPv6
>address and assume that's an IPv4 address, which will not work.
>
>If client software doesn't work, and the users or testers report, "There's
>a message in syslog about error 14," then the issue enters the software
>writer's consciousness, and they investigate why it's happening, and fix
>their software.
>
>The longer we let client software writers remain blissfully unaware that
>they're inadvertently requesting an IPv6 address, the bigger problem we're
>creating for ourselves when gateways start honouring the client request and
>actually start returning IPv6 addresses.
>
>Stuart Cheshire
>

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Jun 2013 11:32:47 -0700

> I understand your concern but defining a new error code will create a new connectivity failure case if the client does not try another request with the adjusted Suggested External IP Address. But w…

Because the *human* writing the code cannot avoid noticing that their code doesn't work, so they will fix it.

What makes you think that a "poor" implementation, that today only handles one address family, will somehow spontaneously grow a new piece of code, in the field, two years from now, which enables it to correctly handle replies containing the other address family that it currently knows nothing about?

Stuart Cheshire

---

From: <[email-masked]>
Date: Thu, 13 Jun 2013 08:16:55 +0200

Please see inline.
Cheers,
Med

>Envoyé : mercredi 12 juin 2013 20:33
>À : [email-masked]
>> * I'm more concerned about how a client can get connectivity and how the
>server can help in maximizing the chance to honor a request
>>
>> I understand your concern but defining a new error code will create a new
>connectivity failure case if the client does not try another request with
>the adjusted Suggested External IP Address. But what are the guarantees a
>"poor" implementation will try another adjusted request?
>
>

[Med] This is part of the basic test cases to be conducted (no matter the error code is defined or not).

>
>What makes you think that a "poor" implementation, that today only handles
>one address family, will somehow spontaneously grow a new piece of code, in
>the field, two years from now, which enables it to correctly handle replies
>containing the other address family that it currently knows nothing about?
>
[Med] You can expect anything from a "poor" implementation. This is the point behind the question I raised above. We should not exacerbate connectivity failures because of some design choices motivated by the behavior of "poor" implementations. Instead of creating a new error code, sketching recommendations for the client to increase its chance to get connectivity such as recall implementors about basic PCP design choices, e.g.: (1) the PCP server should service a valid request; no need to return an error (as you rightfully mentioned in slide 7 of http://www.ietf.org/proceedings/80/slides/pcp-8.pdf), (2) a PCP client is not aware of the external AF managed by the PCP server; it should be prepared to receive a AF not matching the one indicated in the suggested field.

Of course a PCP client that wants to retrieve all AFs, will need to send two requests to the server. The server will return two mappings or only the same mapping for both requests.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2013 15:56:00 +0000

Med, under what circumstances would a good implementation that is aware of the UNSUPP_FAMILY error code fail to get the connectivity it needed?

---

From: <[email-masked]>
Date: Fri, 14 Jun 2013 07:44:42 +0200

Hi Ted,

Please see inline.

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : jeudi 13 juin 2013 17:56
>Med, under what circumstances would a good implementation that is aware of
>the UNSUPP_FAMILY error code fail to get the connectivity it needed?

[Med] If it does not **systematically** re-send the request with another AF after receiving an UNSUPP_AF error. Please refer to the table I provided here: http://www.ietf.org/mail-archive/web/pcp/current/msg03081.html. We don't have that risk if we assume a good implementation should be prepared to receive any AF from the server.  

BTW, a client is not aware of the AF supported by the server. So suggested external IP address is only a hint to create the mapping; which is only a means to provide connectivity. 

Take the example of an IPv6-only host located behind a NAT64: the host is not aware external IPv4 @es are managed by the NAT64. How that client will adjust the AF of the suggested external address field? My take on this is it should not have any preference.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 10:18:46 +0000

> [Med] If it does not **systematically** re-send the request with another AF after receiving an UNSUPP_AF error. Please refer to the table I provided here: http://www.ietf.org/mail-archive/web/pcp/c…

So your point is that a PCP client that supports IPv6 connections might not ask for an IPv6 connection.   Stuart's point is that a client that doesn't support IPv6 connections might get an IPv6 connection and crash.

The downside in your case is that a broken client doesn't get service.   The downside in Stuart's case is that a service has to be shut off to avoid breaking broken clients.

This seems like an easy decision.

---

From: <[email-masked]>
Date: Fri, 14 Jun 2013 13:27:47 +0200

Please see inline.

>Envoyé : vendredi 14 juin 2013 12:19
>> [Med] If it does not **systematically** re-send the request with another
>AF after receiving an UNSUPP_AF error. Please refer to the table I provided
>here: http://www.ietf.org/mail-archive/web/pcp/current/msg03081.html. We
>don't have that risk if we assume a good implementation should be prepared
>to receive any AF from the server.
>
>So your point is that a PCP client that supports IPv6 connections might not
>ask for an IPv6 connection.
[Med] I guess you meant IPv4 connection. 

   Stuart's point is that a client that doesn't
>support IPv6 connections might get an IPv6 connection and crash.
[Med] This is what I'm objecting: we should not constraint the protocol because of the behavior of some "poor" implementations. This can be fixed by re-iterating PCP design choices: the server should service a well formed request + the client should be prepared to receive any AF from the server.

>
>The downside in your case is that a broken client doesn't get service.
>The downside in Stuart's case is that a service has to be shut off to avoid
>breaking broken clients.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 11:40:42 +0000

> [Med] I guess you meant IPv4 connection. 

No, I mean an IPv6 connection.   But it could go either way, sure.

> [Med] This is what I'm objecting: we should not constraint the protocol because of the behavior of some "poor" implementations. This can be fixed by re-iterating PCP design choices: the server shou…

Right, you are making an asymmetric assumption: that clients will be broken in the sense that they will not ask for a connection they could otherwise support, but will not be broken in the sense that they will not correctly support a connection the implementor didn't anticipate them getting.

I don't think this is reasonable.   Clients can be broken in both ways; the question is, what is the downside to each form of brokenness.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 18 Jun 2013 15:04:21 -0700

> Right, you are making an asymmetric assumption: that clients will be broken in the sense that they will not ask for a connection they could otherwise support, but will not be broken in the sense th…

Good observation.

A client could be broken in that it asks for IPv6, but actually only handles IPv4 replies.

Now the question is, who should suffer in this case?

(a) The client, which fails to get IPv4 until it is fixed to actually ask for what it wants, or
(b) The gateway, which cannot offer IPv6 addresses until the broken clients get fixed.

In case (a) the client vendor has a clear incentive to update their client so that it works. Effort and reward are aligned.
In case (b) the gateway vendor has little leverage to get the client vendor to fix their client, but the gateway vendor feels the pain (the broken client "appears" to work with other gateways that don't support IPv6, and this new IPv6-capable gateway "appears" to break those existing "good" clients). The IPv4-only client vendor has has little economic justification to put out a costly software update just so that the gateway vendor can support this new IPv6 thing that the client doesn't even care about.

Stuart Cheshire