Normal IPv6 address:
| Lead | Supernet | Subnet | Local | Total |
| 3 bits | 53 bits | 16 bits | 64 bits | 128 bits |
| 2000::/3 | assigned by an RIR such as ARIN or an LIR such as an ISP ARIN allocates addresses to | Your /48 | the local subnet mask is always 64 bits. |
ERMPI6 address:
| Lead | AS | Supernet | Subnet | Local | Total |
| 8 bits | 24 bits | 24 bits | 8 bits | 64 bits | 128 bits |
| e.g. 3f00::/8 | The lower 24 bits of the autonomous system number of any transit provider who knows a local route to your network | assigned by an RIR such as ARIN | Your /56 | the local subnet mask is always 64 bits. |
Routes in the default free zone (DFZ):
Each AS which connects one or more ERMPI6 customers must announce a single /32 route into the DFZ covering their own AS number. No other DFZ routes are required.
DNS for routes:
Destination AS knowledge is propagated via DNS under the zone ermpi6.apra with the same hierarchy as the ip6.arpa RDNS zone. Instead of PTR records, ermpi6.arpa holds TXT records in the following format:
aaaaaa:bb[,aaaaaa:bb][,aaaaaa:bb][...]
where:
aaaaaa = hexadecimal encoding of the lower 24 bits of the autonomous system number
which knows a route to this destination
bb = hexadecimal encoding of the priority for this route
Priorities:
00 = always prefer this route
40 = prefer this route
80 = normal
b0 = avoid this route
ff = use this route only as a last resort
Note: it is expected that special authoritative DNS servers with a copy of the DFZ table and local policy rules will construct a different entry for each requestor based on the source address of the query and the computed optimal routing path. Implementation is left up to the vendor with the expectation that competition will reveal the optimal strategy. In the trivial case the destinations are statically programmed into an existing DNS server.
One additional rule to keep things easy to program: if a request is made via UDP, the DNS server must return a response small enough to fit in a UDP packet and must not instruct the requestor to ask again via TCP. The AS list should be statically or dynamically trimmed as necessary to meet this requirement.
Note: it would ordinarily be appropriate to do this with some new DNS record rather than overloading it on TXT. Due to the short time before IPv4 depletion, the author desires something which works out of the box.
DNS for servers:
DNS for servers addressed by ERMPI6 should respond to AAAA queries with the full address including the encoded ASN for each AS that the server considers acceptable for the initial connection attempt. This will generally be from that special server and will be optimally ordered. If the server is known to support the ERMPI6 additions to the IPv6 protocol then the DNS server may also add an extra TXT record to the response containing the string "ermpi6". A host receiving that string may but is not required to assume that the server supports full ERMPI6.
ERMPI6 negotiation:
A host which wishes to interact with any other Internet host in full ERMPI6 mode must negotiate the start of that mode with the remote host. It does this by originating a ERMPI6 request packet to the address of that host with which it has been communicating. The request packet is a UDP packet to port XX containing a single byte with the value 0xE6.
The request should first be attempted with the preferred source and destination IPv6 addresses. If no response is received, the request may be retried from any source ERMPI6 addresses verified with an ermpi6.arpa lookup and may be sent to any destination ERMPI6 addresses verified with an ermpi6.arpa lookup. If no response is received, the originating host may continue making attempts with an exponential backoff.
If a port unreachable or any response that is not exactly 2 bytes long is received, then the remote host does not support ERMPI6. The originating host should cache this result for at least 5 minutes but no more than 24 hours. Any other response (including host unreachable) should be treated the same as no response.
If the host receives a response UDP packet containing 2 bytes then it may enter full ERMPI6 mode with the remote host. The two bytes is the timeout in seconds for which the originating host may remain in full ERMPI6 mode with the remote host before making another ERMPI6 request.
ERMPI6 negotiation should be attempted:
1. Whenever an ERMPI6 host in endpoint mode engages in a non-trivial amount of
communication with a remote host, or
2. Whenever retransmission timeout characteristics suggest that there is a problem
communicating with the remote host.
ERMPI6 startup mode:
[fixme: hosts with a single IP address which are communicating with hosts with two or more ermpi6 addresses need to be able to enter full mode. Duh.]
A host which supports ERMPI6 must start up in normal IPv6 mode. In this mode it is permitted to request ERMPI6 routing information from the ermpi6.arpa zone, but it may only use this information in a manner consistent with normal IPv6 operations. For example, if an application requests a TCP connection to a remote host with ERMPI6 routing information, the host may alter the AS number encoded in the destination address during the SYN packet retries but once the TCP connection is established it must continue using the exact IPv6 address for which the connection was successful. In particular, the host must not negotiate full ERMPI6 mode with other hosts and must only accept packets for its explicitly configured IPv6 addresses, including the full AS number.
ERMPI6 endpoint mode:
A host which supports ERMPI6 may attempt to enter endpoint mode whenever it is configured with two or more global scope addresses which differ only in the 24 AS bits. It will make an anycast UDP DNS request for the ermpi6.arpa record for any of its respective IPv6 addresses. If the response includes a validly formatted ERMPI6 destination AS map with at least two AS numbers then the host enters ERMPI6 endpoint mode.
Endpoint mode is exactly the same as startup mode except for four differences:
1. The host must accept packets to its address regardless of the value of the AS
component even if that particular address is not configured on the host,
2. The host must treat packets from remote hosts in the ERMPI6 range where only the AS
component differs as being interchangeable and from the same host,
3. The host is permitted to request ERMPI6 mode with any remote host with which it
communicates, and
4. The host must respond to an ERMPI6 request packet with an appropriate response packet.
ERMPI6 full mode:
After completing ERMPI6 negotiation, a host enters in full ERMPI6 mode with the destination host. In full ERMPI6 mode, the originating host may change the AS value in its own address or in the remote host's address as allowed by the ermpi6.arpa DNS entries with the expectation that the remote host will understand that the addresses are really the same.
Note that the remote host may not assume the originating host supports ERMPI6 merely because it behaves in this manner. It must make its own ERMPI6 request, receive an ERMPI6 reply and look up the originating host's ermpi6.arpa DNS entry. This is a necessary step in authenticating and securing ERMPI6 use with the originating host.
Routing and filtering considerations:
An EMRPI6-aware router should squash the AS number portion of the destination address when making its routing decision. While not strictly required, it will tend to make things work more smoothly. It should also squash the AS when filtering packets from ERMPI6 customers such that those customers may set any AS in the source address of the outbound packets. If the service provider's router is not ERMPI6 aware then it must be configured to allow the injection of packets with any source AS to which the customer network is connected.
A router or firewall on a network with ERMPI6 hosts which will enter ERMPI6 endpoint mode must be sufficiently ERMPI6-aware to filter out spoofed packets claiming to be from the local subnet with an alternate AS and to permit valid packets regardless of the AS value.