Draft: draft-age-masque-connect-ip

Commentary: This PR is one potential way to It simplifies route exchanges by going with 's suggestion of sending the entire routing table each time something changes . It could be somewhat inefficient in some cases , but it becomes easier to reason about than what 's currently in the draft when overlapping prefixes are involved . 
 This is interesting , but I 'd prefer to wait to do this until after we post a -00 version . is that OK with you ? 
 I 'd prefer we figure this out before -00 , because this would be a pretty significant non - compatible change and I 'd like to implement -00 
 you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why . Can you outline your reasoning again ? 
 my argument was that we should n't have two different ways to set routes , one that gives a table and one that gives a single route . If we go to only have a table , then it 's fine . 
 I know saw the discussion in and support this approach . Also if we agree on this approach , I also think we should merge it before we submit -00 
 I think we 're ready to merge this PR 
 As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table is n't as simple as initially expected . This is because two separate capsules can describe prefixes that are distinct but overlap . We should simplify the design or better explain the caveats . 
 I think this looks good enough to include in the -00 .
Paragraph (version A):
Along with a successful response, the proxy can send capsules to
assign addresses and routes to the client (capsules).  The client can
also assign addresses and routes to the proxy for network-to-network
routing.
Paragraph (version B):
Along with a successful response, the proxy can send capsules to
assign addresses and advertise routes to the client (capsules).  The
client can also assign addresses and advertise routes to the proxy
for network-to-network routing.
Paragraph (version B):
The number of bits in the IP Address that are used to define the
prefix that is being assigned.  This MUST be less than or equal to
the length of the IP Address field, in bits.  If the prefix length
is equal to the length of the IP Address, the receiver of this
capsule is only allowed to send packets from a single source
address.  If the prefix length is less than the length of the IP
address, the receiver of this capsule is allowed to send packets
from any source address that falls within the prefix.
Paragraph (version A):
IP Version of this route advertisement.  MUST be either 4 or 6.
Paragraph (version A):
IP address of the advertised route.  If the IP Version field has
value 4, the IP Address field SHALL have a length of 32 bits.  If
the IP Version field has value 6, the IP Address field SHALL have
a length of 128 bits.
Paragraph (version A):
The number of bits in the IP Address that are used to define the
prefix of the advertised route.  This MUST be lesser or equal to
the length of the IP Address field, in bits.  If the prefix length
is equal to the length of the IP Address, this route only allows
sending packets to a single destination address.  If the prefix
length is less than the length of the IP address, this route
allows sending packets to any destination address that falls
within the prefix.
Paragraph (version A):
The Internet Protocol Number for traffic that can be sent to this
prefix.  If the value is 0, all protocols are allowed.
Paragraph (version A):
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start
routing IP packets in that prefix to its peer.
Paragraph (version A):
If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of
the advertised routes can be used.  For example, multiple
ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both
IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL
capsules.
Paragraph (version A):
IP Version of this route withdrawal.  MUST be either 4 or 6.
Paragraph (version A):
IP address of the withdrawn route.  If the IP Version field has
value 4, the IP Address field SHALL have a length of 32 bits.  If
the IP Version field has value 6, the IP Address field SHALL have
a length of 128 bits.
Paragraph (version A):
The number of bits in the IP Address that are used to define the
prefix of the withdrawn route.  This MUST be lesser or equal to
the length of the IP Address field, in bits.
Paragraph (version A):
The Internet Protocol Number for traffic for this route.  If the
value is 0, all protocols are withdrawn for this prefix.
Paragraph (version A):
Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop
routing IP packets in that prefix to its peer.  Note that this
capsule can be reordered with DATAGRAM frames, and therefore an
endpoint that receives packets for routes it has rejected MUST NOT
treat that as an error.
Paragraph (version A):
ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in
order of receipt: if a prefix is covered by multiple received
ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last
received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT
and ROUTE_WITHDRAWAL capsules for this prefix.
Paragraph (version B):
The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the
capsule type) allows an endpoint to communicate to its peer that it
is willing to route traffic to a set of IP address ranges.  This
indicates that the sender has an existing route to each address
range, and notifies its peer that if the receiver of the
ROUTE_ADVERTISEMENT capsule sends IP packets for one of these ranges
in HTTP Datagrams, the sender of the capsule will forward them along
its preexisting route.  Any address which is in one of the address
ranges can be used as the destination address on IP packets
originated by the receiver of this capsule.
Paragraph (version B):
The ROUTE_ADVERTISEMENT capsule contains a sequence of IP Address
Ranges.
Paragraph (version B):
IP Version of this range.  MUST be either 4 or 6.
Paragraph (version B):
Inclusive start and end IP address of the advertised range.  If
the IP Version field has value 4, these fields SHALL have a length
of 32 bits.  If the IP Version field has value 6, these fields
SHALL have a length of 128 bits.  The Start IP Address MUST be
strictly lesser than the End IP Address.
Paragraph (version B):
The Internet Protocol Number for traffic that can be sent to this
range.  If the value is 0, all protocols are allowed.
Paragraph (version B):
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start
routing IP packets in these ranges to its peer.
Paragraph (version B):
Each ROUTE_ADVERTISEMENT contains the full list of address ranges.
If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction,
each ROUTE_ADVERTISEMENT capsule supersedes prior ones.  In other
words, if a given address range was present in a prior capsule but
the most recently received ROUTE_ADVERTISEMENT capsule does not
contain it, the receiver will consider that range withdrawn.
Paragraph (version B):
If the IP Version of A and B are equal, the IP Protocol of A MUST
be lesser or equal than IP Protocol of B.
Paragraph (version B):
If the IP Version and IP Protocol of A and B are both equal, the
End IP Address of A MUST be strictly lesser than the Start IP
Address of B.
Paragraph (version B):
If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not
meet these requirements, it MUST abort the stream.
Paragraph (version A):
In this case, the client does not specify any scope in its request.
The server assigns the client an IPv6 address prefix to the client
(2001:db8::/64) and a full-tunnel route of all IPv6 addresses (::/0).
The client can then send to any IPv6 host using a source address in
its assigned prefix.
Paragraph (version A):
A setup for a split-tunnel VPN (the case where the client can only
access a specific set of private subnets) is quite similar.  In this
case, the advertised route is restricted to 2001:db8::/32, rather
than ::/0.
Paragraph (version B):
In this case, the client does not specify any scope in its request.
The server assigns the client an IPv4 address to the client
(192.0.2.11) and a full-tunnel route of all IPv4 addresses
(0.0.0.0/0).  The client can then send to any IPv4 host using a
source address in its assigned prefix.