[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPv6 Pain Experiment
- Subject: IPv6 Pain Experiment
- From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
- Date: Mon, 7 Oct 2019 15:03:51 +0900
- In-reply-to: <CAKsZx=1BbiM34kav1BjFEOYhzxqr+gPjfReD8H_=sra=RdMFBA@mail.gmail.com>
- References: <[email protected]> <[email protected]> <[email protected]> <277355.1570399119@turing-police> <CAKsZx=1BbiM34kav1BjFEOYhzxqr+gPjfReD8H_=sra=RdMFBA@mail.gmail.com>
Forrest Christian (List Account) wrote:
> I've been ignoring this discussion because I feel this ship sailed
> many years ago, and IPv6, like it or hate it, is the best way
> forward we have.
A problem is that there is a cliff edge in front of you.
> But, assuming you're expanding the address space, the simplest
> solution is to add the additional bits addresses at the end.
Sure.
> On the other hand, this sure seems similar to what we do today with
> CGNAT and similar today since there are already 64K endpoints in
> both TCP and UDP per ./32 of IP....
The following draft makes it more explicit:
https://tools.ietf.org/html/draft-ymbk-aplusp-10
The A+P Approach to the IPv4 Address Shortage
R. Bush, Ed.
Instead of assigning a single IPv4 address to a
single customer device, we propose to extend the
address field by using bits from the port number
range in the TCP/UDP header as additional end point
identifiers,
A+P is equivalent to NAT with end to end transparency.
Masataka Ohta