Is anyone working on an update to include IPv6?
What part of BCP-38 do you think needs to be updated to support IPv6?
Changing the examples to use IPv6 documentation prefixes instead of IPv4
documentation prefixes?
Mark
For a start, *add* IPv6 examples in parallel with the IPv4 examples. As
RFCs are peer reviewed, if the examples expose a hole or problem then
the hole can be filled or the problem resolved.
BCP-38 should be reviewed in whole for "IPv6" completeness, and the
preamble of BCP-38 add that the Best Practices include complete
recommendations for both IPv4 and IPv6.
One specific example:
BCP-38 currently references RFC1812, _Requirements for IP Version 4
Routers_.
It appears that the only parallel paper for IPv6 is
draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which
currently carries a copyright of 2018. It's a shame that this document
is still in limbo; witness this quote: "It is inappropriate to use
Internet-Drafts as reference material or to cite them other than as
'work in progress.'
Someone else mentioned that "IPv6 has been around for 25 years, and why
is it taking so long for everyone to adopt it?" I present as evidence
the lack of a formally-released requirements RFC for IPv6. It suggests
that the "science" of IPv6 is not "settled" yet. That puts the
deployment of IPv6 in the category of "experiment" and not "production".
Is that really true?
There may be more issues. And, yes, I understand that a new BCP paper
may result -- I don't care how it's labeled, as long as it's done. Or
has such a BCP document already been released? If so, why do I not see
any references to it here on NANOG, or anywhere else?
Why do I care, you ask. I'm working on a BCP-38 module proposal for
firewalld, one that can be peer-reviewed for accuracy and completeness.
Servers running that firewall package can then be easily configured to
conform to the requirements of BCP-38 and can easily become good
net-citizens in their own right.
So I call for draft-ietf-v6ops-ipv6rtr-reqs-04 to be finished and
released as a formal RFC, and that BCP-38 be updated to refer to that
finished RFC.
Until that is done, my BCP-38 module will have to carry a "work in
progress" disclaimer.
1000 times +1
We need (much) more IPv6 examples!
It appears that the only parallel paper for IPv6 is
draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which
currently carries a copyright of 2018. It's a shame that this document
is still in limbo; witness this quote: "It is inappropriate to use
Internet-Drafts as reference material or to cite them other than as
'work in progress.'
Speaking as v6ops chair and the editor of record for 1812. draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be an 1812-like document and adopted as such, but many of the "requirements" that came out of it were specific to the author's operation and not common to other operators. So it ultimately didn't happen.
Someone else mentioned that "IPv6 has been around for 25 years, and why
is it taking so long for everyone to adopt it?" I present as evidence
the lack of a formally-released requirements RFC for IPv6. It suggests
that the "science" of IPv6 is not "settled" yet. That puts the
deployment of IPv6 in the category of "experiment" and not "production".Is that really true?
That's a long story. The IETF realized it needed a next generation protocol in 1990; that's where NATs came from, the successive efforts to recover unused IPv4 space, and research into possible next generation protocols. IPv6 was proposed in 1993-1994, originally published in 1996 as RFC 1883, and republished in 1998 as RFC 2460. It was recently re-re-published as RFC 8200.
Supporting work was required in DHCP, DNS, and several routing protocols; that happened over time. ICANN didn't adopt a policy for the allocation of IPv6 address space to RIRs until 2006, and in 2007 there were a number of allocations from IANA to the RIRs and from some of the RIRs to operators in various parts of the world. Testing was also important - primarily done by the NRENs. That wound up with comments going back to various vendors. I was employed by one of them, but will refrain from giving "insider" comments. Suffice it to say that there were multiple vendor implementations, mostly incomplete in one way or another.
IANA allocated the last five IPv4 /8s to the RIRs in 2011, and since then the IPv4 address market has been mopping up the slop. Per https://ipv4marketgroup.com/ipv4-pricing/ (if addresses were real estate, ipv4marketgroup would be a real estate agent), the price of an address was stable at or near $10/address from several years, and in 2016-2018 shot to about $18/address. They expect the price to start to fall in the next year or so, as CIOs figure out that its a waste of money.
There is no demand until further IPv4 deployment no longer suffices. I would say that there was no real market demand until after January 2011, and probably 2012 or 2013.
At this point, there is fairly wide deployment among the ISP and CDN operators, and vendor implementations are fairly complete. Google, APNIC, and Akamai report on traffic levels; Google says that they see at least 5% of the requests they receive from 61 countries use IPv6, and from one country a tad more that half of the requests they receive use IPv6. https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=be,yt,de,gr,my,vn,in,gf,us,uy,fr,tw,jp,lu,ch,mx,br,pt,fi,mq,ax,th,ee,re,hu,gb,ca,gp,tt,ie,lk,nz,au,pe,ec,nl,ae,ro,ga,bo,sa,sx,cz,no,si,sg,pl,gt,at,mo,ar,mm,kr,fo,om,lv,zw,pr,ke,tg,ba. And interesting point in those reports is that Google and Akamai are CDNs, which means that (for the most part) a request goes almost directly from a user's broadband interface to the service in question. APNIC is different in that it operates no CDN; requests they receive cross the backbone, and therefore also measure backbone deployment. To that matter, let me list the APNIC charts of the top ten:
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=YT
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=DE
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=GR
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=MY
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=VN
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=GF
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=US
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=UY
In each of those, APNIC measures and reports a distinction between a requestor being "IPv6 Capable" and "Preferring IPv6". This is done using a google ad that includes three one-pixel links; one of the names has only an A record, one has only a AAAA record, and one bas both. If the requestor uses the first two links and APNIC receives the SYN, then the end system and every AS en route used and provided an IPv4 or IPv6 capability respectively. In the third case, the end system presumably gets both an IPv4 and an IPv6 address, and makes a choice. If it chooses IPv6, it is reported as preferring IPv6. If you select the links above, you will find that end systems (telephones, laptops, whatever) will generally prefer IPv6 if given the option.
Also interesting on those pages, APNIC lists the ASNs serving the indicated country, and separates requests by ASN. For example, in India (https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN), APNIC reports on 100 different ASNs, of which half demonstrate non-trivial IPv6 traffic, and (I think) 20 demonstrate more than 10%. A celebrated one among them is Reliance JIO; https://stats.labs.apnic.net/ipv6/AS55836?c=IN&p=1&v=1&w=30&x=1. You might look at that chart, as it breaks out Reliance JIO and "rest of country". Reliance was a new operator in 2011, and as I understand the story got a small allocation from APNIC (in accordance with its policies) and went to the market to purchase IPv4 address space. They recognized the expense of that approach in perhaps 2015, and started IPv6 deployment. At that time, they were probably the only, or at least the principal, operator using IPv6 AT ALL in that country. What the data shows is that other operators - half of those in India - have since then followed suit, probably due in part to competitive pressure.
So we see IPv6 in broadband, in ISPs, and in telephone networks. To give you an anecdote, my kids have teased me about IPv6 for years, and each now have IPv6 service from their various ISPs and telephone networks despite themselves - and use it for the majority of their accesses.
What is visibly lacking is enterprise deployment. There are companies that have it, but they are unusual; those that are visible in routing usually have it for their outward-facing services such as mail and web, but not internally. To be very honest, some of that leaves me cross-eyed. A recent example I was asked to give advice on - name consciously left out - was a country that wanted to deploy an NREN that would enable certain services to some 5000 secondary and university-level schools. If they deployed it using IPv4, simply buying the addresses would have cost them $25M; equipment and personnel are not included in that expense. From their RIR, getting the smallest allocation the RIRs give to an ISP - an IPv6 /32 - would cost $2100/month., and would give them allocations for 65535 such end sites. So they have a choice: $25M up front, or $2100/month. Hmm, that's a hard one... MIT recently sold half of their IPv4 address space - 1 /9 out of a /8 - to Amazon, and stated in a blog that they planned to use the proceeds for their IPv6 deployment. A company that I am on the board of independently from me decided to sell half of its legacy /16, and use the proceeds for internal projects. If I were an enterprise CIO, I would see that address space as banked money, and want to access it. I'm obviously clueless - that's not happening.
And on lists like this, I am told that there is no deployment - that nobody wants it, and anyone that disagrees with that assessment has lost his or her mind. That all leaves me wondering which of us doesn't quite have their eye on the ball.
And, of course, we now have companies like T-Mobile and others turning IPv4 off. If that's an experiment, wow.
The cellular data industry appears to have embraced IPv6 in one form or
another. I would expect that the network engineers have done some work
to keep IPv4 off their *internal* networks, but provide IPv4 access at
the edge. (Isn't a netblock within IPv6 intended to enable bridging to
IPv4?) The applications on the phon could be configured to search DNS
for AAAA addresses first.
My AT&T cell phone has both IPv4 and IPv6 addresses. The IPv4 address
is from my access point; the IPv6 address appears to be a public address.
I would like to move to IPv6. I just don't want to shoot myself in the
foot, or cause trouble for other people, by being sure my edge router
"follows all the rules."
Speaking as v6ops chair and the editor of record for 1812.
draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be
an 1812-like document and adopted as such, but many of the
"requirements" that came out of it were specific to the author's
operation and not common to other operators. So it ultimately didn't happen.
Sympathies. I've been involved in Standards-setting committees, so I
know how that works. Is there any further work being done? And just
how much of the current draft can be generalized?
There is no demand until further IPv4 deployment no longer suffices.
I would say that there was no real market demand until after January
2011, and probably 2012 or 2013.>
At this point, there is fairly wide deployment among the ISP and CDN
operators, and vendor implementations are fairly complete. Google,
APNIC, and Akamai report on traffic levels; Google says that they see
at least 5% of the requests they receive from 61 countries use IPv6,
and from one country a tad more that half of the requests they
receive use IPv6.>
So we see IPv6 in broadband, in ISPs, and in telephone networks. To
give you an anecdote, my kids have teased me about IPv6 for years,
and each now have IPv6 service from their various ISPs and telephone
networks despite themselves - and use it for the majority of their
accesses.>
What is visibly lacking is enterprise deployment.
Interesting you should mention that. One reason I wanted to do an
IPv6-aware BGP-38 module for firewalld was to help break that logjam.
Enterprises are risk-adverse, which is why adoption meets such strong
resistance.
And on lists like this, I am told that there is no deployment - that
nobody wants it, and anyone that disagrees with that assessment has
lost his or her mind. That all leaves me wondering which of us
doesn't quite have their eye on the ball.
For the reasons you provided in your original message, the learning
curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" --
is steep and uncertain.
And I think you may be misunderstanding the problem. It's not that
people don't want it. They lack the zen of it, they don't see the four
corners of the thing, something that people took years to learn in IPv4.
(I had a leg up, being involved in the original ARPAnet, so I got to
watch it grow. Still have the 1984 DDN handbooks, too.)
On 10/3/19 8:42 AM, Fred Baker wrote:
Someone else mentioned that "IPv6 has been around for 25 years, and why
is it taking so long for everyone to adopt it?" I present as evidence
the lack of a formally-released requirements RFC for IPv6. It suggests
that the “science” of IPv6 is not “settled” yet. That puts the
deployment of IPv6 in the category of “experiment” and not “production”.
And, of course, we now have companies like T-Mobile and others
turning IPv4 off. If that’s an experiment, wow.
The cellular data industry appears to have embraced IPv6 in one form or
another. I would expect that the network engineers have done some work
to keep IPv4 off their internal networks, but provide IPv4 access at
the edge. (Isn’t a netblock within IPv6 intended to enable bridging to
IPv4?) The applications on the phon could be configured to search DNS
for AAAA addresses first.
T-Mobile documented what they are doing at https://tools.ietf.org/html/rfc6877.
My AT&T cell phone has both IPv4 and IPv6 addresses. The IPv4 address
is from my access point; the IPv6 address appears to be a public address.
So does my T-Mobile phone. It got the IPv4 address from my friendly neighborhood WiFi.
Funny thing. I was quoting the email in this thread just prior to yours. I won’t say there are no issues in IPv6 deployment; there are. However, having done some myself, if you have IPv4-zen, IPv6-zen is pretty easy to come by with a cheat sheet. For example, does your configuration have statements like
IP address 192.0.2.1 255.255.255.0 ?
Everywhere you find that, you add a statement like
ipv6 address 2001:db8:AABB:1234::/64 eui-64
What I did for the IID (IPv4-speak: “host part”) in a recent project was use the IPv4 address of the interface:
IP address 192.0.2.1 255.255.255.0
IPv6 address 2001:db8:aabb:1234:192:0:2:1::/128
The idea was to give the operator a clue. I also put the VLAN number in as the subnet number. A security geek would be all over me - “too many clues!”. That said,
I found that by typing “IPv6 address command” into google; the first hit was [https://study-ccna.com/how-to-configure-ipv6/](https://study-ccna.com/how-to-configure-ipv6/). Then, noting that Cisco has a bad habit of pulling things out of there air even though there is a defined way to accomplish it, I corrected the prefix to use the defined documentation prefix.
It gets a little interesting when you step away from the switch or router to the firewall; they have their own commands. The ASA, for example, really believes in what Cisco calls “zone-based access control” or “context-based access control”. The good news is that if that’s what you’re trying to achieve (it’s common), configuring that for IPv6 is pretty simple.
And similarly, BGP and access lists look a lot like their IPv4 counterparts.
What’s a little more of a pain is that if you are using other appliance in your network, they may or may not have IPv6 configurability, and there may or may not be a drop-in replacement. That becomes a conversation with your vendors of choice.
For a start, *add* IPv6 examples in parallel with the IPv4 examples.
1000 times +1
We need (much) more IPv6 examples!
Have you read BCP-38? Is there anything in there that really needs IPv6
examples to make it clear?
BCP-38 is “if the source address of the packet coming from the site isn’t a
address allocated to the site, drop the packet”. I’m sure you can all figure
out how to do that with IPv6 as easily as with IPv4.
Now IPv6 examples are nice but getting several 1000’s people to read draft that
just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, 12.0.0.0/8
and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly
is a waste of time.
Do you really need examples of a TCP SYN Flood attack using IPv6 addresses instead
of IPv4 addresses? Or the network diagram to be changed?
11.0.0.0/8
/
router 1
/
/
/ 204.69.207.0/24
ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
A B C D 2
/
/
/
router 3
/
12.0.0.0/8
In other words, the ingress filter on "router 2" above would check:
IF packet's source address from within 204.69.207.0/24
THEN forward as appropriate
IF packet's source address is anything else
THEN deny packet
Network administrators should log information on packets which are
dropped. This then provides a basis for monitoring any suspicious
activity.
2001:DB8:11:/48
/
router 1
/
/
/ 2001:DB8:204:/48
ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
A B C D 2
/
/
/
router 3
/
2001:DB8:12:/48
In other words, the ingress filter on "router 2" above would check:
IF packet's source address from within 2001:DB8:204:/48
THEN forward as appropriate
IF packet's source address is anything else
THEN deny packet
Network administrators should log information on packets which are
dropped. This then provides a basis for monitoring any suspicious
activity.
Mark
<snip />
A security geek would be all over me - "too many clues!".
Anyone who says something like that is not a "security geek". They are a "security poser", interested primarily in "security by obscurity" and "security theatre", and have no clue what they are talking about. Send them back to the burger assembly line at McDonalds -- they are not even qualified to be flipping the burgers -- only to assemble the final burger from the pre-flipped burgers in the burger drawers. And keep them away from the deep fryer, cash, and the microwave oven.
Amen to that.
If you've been pwned hard enough that vlan numbers are useful to the attacker,
the fact the attacker knows your vlan numbers is the *least* of your problems....
Long ago, I was working on Network Graphics Protocol and the draft RFC
for it. My boss said that I needed to write a couple of paragraphs
about fixed-point binary fractions, which the protocol used, "because
that's not a common thing in the world". How bad was this? The person
who was writing the generator of the NGP stream used *floating point*
because that person didn't understand that 7FFFFFFF was interpreted as a
bitty-point less than 1.0, and 80000001 was a bitty-point less that -1.0
-- and that trying to shoehorn this into IEEE floating-point format
almost worked. What my poor boss didn't realize is that exactly 1.0 and
-1.0 were not defined. The specification didn't make that clear.
When I'm doing technical writing, I find all sorts of corner cases that
were missed by the designers and the QA people. It makes me very
unpopular. But it also makes for a better product, in the end.
So making everything crystal clear and obvious is definitely not "a
waste of time." You have no idea what undiscovered bugs may become
obvious when you go through the exercise and show all your work.
You still need a IPv6 version of RFC 1812. Make it as clean as
possible. Use an ax instead of a XACTO knife on the current draft.
What is the minimum necessary things that a generic IPv6 router MUST do?
Stephen Satchell wrote:
You still need a IPv6 version of RFC 1812. Make it as clean as
possible. Use an ax instead of a XACTO knife on the current draft.
What is the minimum necessary things that a generic IPv6 router MUST do?
As for requirements for IPv6 routers, how do you think about the
following requirement by rfc4443?
Originating a Packet Too Big Message makes an exception to one of the
rules as to when to originate an ICMPv6 error message. Unlike other
messages, it is sent in response to a packet received with an IPv6
multicast destination address, or with a link-layer multicast or
link-layer broadcast address.
rfc1812 says:
4.3.2.7 When Not to Send ICMP Errors
An ICMP error message MUST NOT be sent as the result of receiving:
o A packet destined to an IP broadcast or IP multicast address, or
o A packet sent as a Link Layer broadcast or multicast, or
with reasons.
IPv6 specification is fatally broken in various ways.
Masataka Ohta
As for requirements for IPv6 routers, how do you think about the
following requirement by rfc4443?
44443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed..
March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates
RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET
STANDARD) (DOI: 10.17487/RFC4443)
rfc1812 says:
1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC1812)
I suppose you never considered that in the 11 years intervening, we decided
that maybe things should be done differently.
IPv6 specification is fatally broken in various ways.
Oddly enough, it doesn't seem to be fatally broken from where I am, or
from where Google is, or from where Facebook is, or from where most
of the cellphone companies are.
You must have a different definition of "fatally broken" than the rest of us.
Valdis Kletnieks wrote:
I suppose you never considered that in the 11 years intervening, we decided
that maybe things should be done differently.
I never considered?
I even know that it is called second system syndrome.
Do you?
Masataka Ohta
If we were to start with the current draft, I would probably want to start over, and have people involved from multiple operators.
That said, let me give you some background on RFC 1812. The development started a little after a largish group of people started on what eventually became RFCs 1122 and 1123. The point was that there were a number of RFCs that needed to be updated with hard-earned wisdom - how ARP should work and so on. The group decided that instead of reissuing each individual RFC, they should do one omnibus effort. 1812 similarly covered a lot of "we discovered that this was true or needed to become true". The first editors was Philip Almquist, and it passed through several subsequent pairs of hands. It then sat on a shelf for several years, with people saying "we really should publish that" and not doing so. In 1994, the CIDR change was in full swing, and I was changing employers. Marshall Rose contacted me asking me to take it over, edit CIDR into it and "do whatever else was needed", and publish the thing. My new boss agreed to lt me do so, and I did.
I was given the text in RFC 1716 as input, which was then published as "historic", and RFC 1812 was the end product. RFC 1812 is kind of long in the tooth, BTW.
Since then, the way the IETF updates documents with hard-earned wisdom has changed. We don't do omnibus documents like RFC 1122/1123 and 1812; we write a document - or 20 of them - that "update" the document in question. You can find that information in the rfc-index.txt file, and in the datatracker. So if there were updates to include corresponding to those RFCs and on IPv6, I think the IETF would tell you to look at RFC 8200.
There is one thing in 1122/1123 and 1812 that is not in those kinds of documents that I miss; that is essentially "why". Going through 1122/1123 and 1812, you'll ind several sections that say "we require X", and follow that with a "discussion" section that says "we thought about X, Y, and Z, there were proponents of each, the arguments were X', Y', and Z', and we chose X for this reason". I would presume that what you're really looking for in a 1812-for-IPv6 is not "we require X" as much as "for this reason". Correct me if I'm wrong.
I can kick the idea around in the IETF if its important to you. I'll be looking for a LOT of operational input.
There is one thing in 1122/1123 and 1812 that is not in those kinds
of documents that I miss; that is essentially "why". Going through
1122/1123 and 1812, you'll ind several sections that say "we require
X", and follow that with a "discussion" section that says "we thought
about X, Y, and Z, there were proponents of each, the arguments were
X', Y', and Z', and we chose X for this reason". I would presume that
what you're really looking for in a 1812-for-IPv6 is not "we require
X" as much as "for this reason". Correct me if I'm wrong.
Ah. What I'm looking for is a list of check-boxes to include in an
implementation specification for an edge router. It can be references
to a whole bunch of RFCs and "packaged" as a BCP. The discussions you
describe are better in the individual papers.
Side note: I'm used to rationales being included in Standards, and
welcome them, as long as they are normative and clearly marked so.
I can kick the idea around in the IETF if its important to you. I'll
be looking for a LOT of operational input.
It could well me that the data is there, we just need a document to
index it all. That's what I thought a BPC was supposed to be. It would
be like an article in ACM Computing Surveys, which references the
existing literature, as opposed to being created from whole cloth.
I think I steered everyone wrong when I was talking about some of the
exposition in the text, specifically the examples. That kind of
material really belongs in an RFC. My apologies.
Look at CableLabs specifications. There is also RFC 7084, Basic Requirements
for IPv6 Customer Edge Routers which CableLabs reference.
Also RFC 8585, Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
Mark