RE: Update to BCP-38?
On Friday, 4 October, 2019 16:05, William Herrin wrote: >On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote: >> On Thursday, 3 October, 2019 11:50, Fred Baker >> wrote: >>> 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. > It's called "operations security" or "OPSEC." The idea is that from lots > of pieces of insignificant information, an adversary can derive or infer > more important information you'd like to deny to him. There's a 5-step > process used by the U.S. Military but the TL;DR version is: if you don't > have to reveal something, don't. You and I have completely different opinions of how security works. In my world, security must continue to be effective even in the face of an adversary that knows everything there is to know about what is being attacked (except for some authentication secrets, which of course need to be kept secret). If the attacker does not already have that information, then obtaining it is usually a rather trivial reconnaissance operation. The job of "securing" something means to make it impervious to outside influence -- it is the other side of the "safety" coin -- and Safety and Security go hand in hand. Security based on keeping something which is trivial to discover secret is trivial security and can still be trivially bypassed. It is telling that of the thousands of "ransomware attacks" that occur each second, only 617 have been successful so far this year. Those victims probably relied on keeping something secret that did not matter. In other words, they expended effort on the wrong things -- their analysis of risk was inherently flawed. Can you provide a scenario in which knowledge of the VLAN number is a vulnerability that can be exploited? And if you can find one, is there a more effective way to prevent that exploit that will work even if the attacker knows the VLAN number? Would it not be more effective to implement that measure than simply using trivial means (that are trivial to defeat) to hide the VLAN number? This does not mean that you need to publish the VLAN numbers on Facebook for all to see, merely that knowledge of that fact is now irrelevant, and that even if the someone posted the VLAN numbers on Facebook for all to see, then that would not be helpful to the adversary. >IMO, anyone who thinks the folks who developed OPSEC don't have a clue is >the one I find wanting. Opinions vary. That is the nature of opinion. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: Update to BCP-38?
On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said: > One of a stupidity, among many, of IPv6 is that it assumes > links have millions or billions of mostly immobile hosts Can somebody hand me a match? There's a straw man argument that needs to be set afire here. pgp1MMtG4U3Ba.pgp Description: PGP signature
Re: IPv6 Pain Experiment
> On Oct 4, 2019, at 20:23 , Owen DeLong wrote: > > > >> On Oct 4, 2019, at 16:48 , Michel Py wrote: >> >>> Owen DeLong wrote : >>> How would you have made it possible for a host that only understands 32-bit >>> addresses to exchange traffic with a host that only has a 128-bit address? >> >> With some kind of NAT mechanism, naturally. >> Which is not possible with the current IPv6 address format, if you want >> something stateless and that does not rely on DNS. > > Well, what address format would you propose that would make it better? Let’s > talk actual workable detailed proposals rather than just hand-waving. > > We already have a number of such solutions: > NAT64 > 464XLAT > B4/AFTR > etc. > >>> How would you have made a 128-bit address more human-readable? Does it >>> really matter? >> >> I have found it difficult to talk hex with people from other countries. Sorry, hit send too soon. Won’t rehash previously posted content, but here’s what got missed… In addition, hex makes it MUCH easier to do subnetting. Each digit aligns with a nibble boundary, so instead of having to memorize/calculate 8 different powers of two ranging from 1-128, you only need to memorize 4 ranging from 0-8. Further, given the bountiful amount of IPv6 space available, you shouldn’t really need to subnet off nibble boundaries unless you really want to. How many people do you know (as a percentage) that divide RFC-1918 space into non-octet-aligned subnets? Remember the handy subnet calculators for IPv4 that broke down all the net mask possibilities: / 9, /17, /25 — .0/.128 (0-127 and 128-255) /10, /18, /26 — .0/.64/.128/.192 (0-63, 64-127, 128-191, 192-255) … /15, /23, /31 — .0/.2/.4/.6/.8/.10/.12/.14/.16/… Yeah, compare that to: /n % 4 = 0 — Aligns with nibble boundary. 1 — 0/8 (0-7, 8-f) 2 — 0/4/8/c (0-3, 4-7, 8-b, c-f) 3 — 0/2/4/6/8/a/c/e (0-1, 2-3, 4-5, 6-7, 8-9, a-b, c-d, e-f) Subnetting is MUCH MUCH MUCH simpler in IPv6, especially if you follow the intended architecture/recommendations. Owen
Re: IPv6 Pain Experiment
> On Oct 4, 2019, at 16:48 , Michel Py wrote: > >> Owen DeLong wrote : >> How would you have made it possible for a host that only understands 32-bit >> addresses to exchange traffic with a host that only has a 128-bit address? > > With some kind of NAT mechanism, naturally. > Which is not possible with the current IPv6 address format, if you want > something stateless and that does not rely on DNS. Well, what address format would you propose that would make it better? Let’s talk actual workable detailed proposals rather than just hand-waving. We already have a number of such solutions: NAT64 464XLAT B4/AFTR etc. >> How would you have made a 128-bit address more human-readable? Does it >> really matter? > > I have found it difficult to talk hex with people from other countries. I haven’t had that much trouble. > Try to say FACEB00C to someone who does not speak your langage. Well, your abuse of the phonetic alphabet might be part of the problem… > Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. Foxtrot, Alpha, Charlie, Echo, colon, Bravo, Zero, Zero, Charlie has worked relatively well for me. > 250.206.176.192 works all the time. Everyone gets the numbers. Really? I’ve actually had more confusion over this… especially five vs. nine (unless I resort to pilot-speak which often confuses them even more). two, five, zero, point, two, zero, six, point, one, seven, six, point, one, nine, two will almost invariably result in some random member of the set: 290.206.176.152 250.206.176.152 250.206.176.192 290.206.176.192 And that’s an address not particularly fraught… Consider, instead: 193.159.155.159 Sometimes I get lucky with one, niner, tree, point, one, fife, niner, point, one, fife, fife, point, one, fife, niner. However, that’s rare. I guess it depends in part on who you are speaking with. Owen > > Michel. > > > > > TSI Disclaimer: This message and any files or text attached to it are > intended only for the recipients named above and contain information that may > be confidential or privileged. If you are not the intended recipient, you > must not forward, copy, use or otherwise disclose this communication or the > information contained herein. In the event you have received this message in > error, please notify the sender immediately by replying to this message, and > then delete all copies of it from your system. Thank you!...
Re: hairpin attempts
it's a dos on my logs. and i do not want to turn hairpin detection off, as there could be interesting things. sigh. :( randy
Re: IPv6 Pain Experiment
On Fri, Oct 04, 2019 at 11:48:33PM +, Michel Py wrote: > > Owen DeLong wrote : > > How would you have made it possible for a host that only understands 32-bit > > addresses to exchange traffic with a host that only has a 128-bit address? > > With some kind of NAT mechanism, naturally. That word "naturally" is doing an *awful* lot of work there. > > How would you have made a 128-bit address more human-readable? Does it > > really matter? > > I have found it difficult to talk hex with people from other countries. > > Try to say FACEB00C to someone who does not speak your langage. > Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. > 250.206.176.192 works all the time. Everyone gets the numbers. That word "Everyone" is doing an *awful* lot of work there. All this hand-waving is creating quite a breeze. Think I'll put on a sweater. - Matt
RE: IPv6 Pain Experiment
> Owen DeLong wrote : > How would you have made it possible for a host that only understands 32-bit > addresses to exchange traffic with a host that only has a 128-bit address? With some kind of NAT mechanism, naturally. Which is not possible with the current IPv6 address format, if you want something stateless and that does not rely on DNS. > How would you have made a 128-bit address more human-readable? Does it really > matter? I have found it difficult to talk hex with people from other countries. Try to say FACEB00C to someone who does not speak your langage. Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. 250.206.176.192 works all the time. Everyone gets the numbers. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: hairpin attempts
On 10/4/19 5:53 PM, Randy Bush wrote: > for some months, our border routers log attempts to connect from the > outside using a source address that is internal to my network. e.g. > > Oct 3 06:48:12 r0 7833: Oct 3 06:48:11.267: %FMANFP-6-IPACCESSLOGP: SIP0: > fman_fp_image: list serial-in4 denied udp 147.28.0.223(3465) -> > 147.28.0.222(53), 1 packet > > some days, we see a *lot* of this. anyone else seeing similar? I also see them. The pattern is the same with a source IP one higher than destination, destination port is always DNS/UDP. Over the last few hours, for example: ipfw: 500 Deny UDP 202.12.127.73:62057 202.12.127.72:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.186:28518 202.12.127.185:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.145:22501 202.12.127.144:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.195:65470 202.12.127.194:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.240:64810 202.12.127.239:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.246:33497 202.12.127.245:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.140:11008 202.12.127.139:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.178:3616 202.12.127.177:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.189:3316 202.12.127.188:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.157:23692 202.12.127.156:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.254:31943 202.12.127.253:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.173:18489 202.12.127.172:53 in via fxp0 ipfw: 500 Deny UDP 202.12.127.242:36058 202.12.127.241:53 in via fxp0 My anti-spoofing rules throw them on the floor since they can't possibly originate on this interface so I haven't investigated further, imb
Re: IPv6 Pain Experiment
> On Oct 2, 2019, at 17:54 , Matt Hoppes > wrote: > > I disagree on that. Ipv4 is very human readable. It is numbers. > > Ipv6 is not human numbers. It’s hex, which is not how we normally county. > > It is all water under the bridge now, but I really feel like ipv6 could have > been made more human friendly and ipv4 interoperable. > >> On Oct 2, 2019, at 8:49 PM, Doug Barton wrote: >> >>> On 10/2/19 3:03 PM, Naslund, Steve wrote: >>> The next largest hurdle is trying to explain to your server guys that you >>> are going to go with all dynamically assigned addressing now >> >> Completely false, but a very common misconception. There is nothing about >> IPv6 that prevents you from assigning static addresses. >> >>> and explaining to your system admin that can’t get a net mask in v4 figured >>> out, how to configure their systems for IPv6. >> >> If they only need an outbound connection, they probably don't need any >> configuration. The instructions for assigning a static address for inbound >> connections vary by OS, but I've seen a lot of them, and none of them are >> more than 10 lines long. >> >> Regarding the previous comments about all the drama of adding DNS records, >> etc.; that is what IPAM systems are for. If you're small enough that you >> don't need an IPAM for IPv4, you almost certainly don't for IPv6. >> >> IPv6 is different, but it's not any more difficult to learn than IPv4. (You >> weren't born understanding IPv4 either.) >> >> Doug OK… Let’s talk about how? How would you have made it possible for a host that only understands 32-bit addresses to exchange traffic with a host that only has a 128-bit address? How would you have made a 128-bit address more human-readable? Does it really matter? IPv4 is not particularly human readable. How many hosts do you keep IPv4 addresses in your head for? How long does it take you to get someone at the other end of a support call to correctly transcribe an IPv4 address? All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, , or both records. Owen
Re: Update to BCP-38?
On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > 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. Keith, It's called "operations security" or "OPSEC." The idea is that from lots of pieces of insignificant information, an adversary can derive or infer more important information you'd like to deny to him. There's a 5-step process used by the U.S. Military but the TL;DR version is: if you don't have to reveal something, don't. IMO, anyone who thinks the folks who developed OPSEC don't have a clue is the one I find wanting. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Update to BCP-38?
Mark Andrews wrote: Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. One of a stupidity, among many, of IPv6 is that it assumes links have millions or billions of mostly immobile hosts and define very large (but not large enough for billions or even millions) minimum interval between ND messages, which is applicable to links with much smaller number of hosts. So, though rfc7084 says; it MUST explicitly invalidate itself as an IPv6 default router on each of its advertising interfaces by immediately transmitting one or more Router Advertisement messages with the "Router Lifetime" field set to zero [RFC4861]. rfc4861 forbids two RAs sent with minimum interval less than 16 seconds. Is it "immediately transmitting one or more Router Advertisement messages"? Masataka Ohta
hairpin attempts
for some months, our border routers log attempts to connect from the outside using a source address that is internal to my network. e.g. Oct 3 06:48:12 r0 7833: Oct 3 06:48:11.267: %FMANFP-6-IPACCESSLOGP: SIP0: fman_fp_image: list serial-in4 denied udp 147.28.0.223(3465) -> 147.28.0.222(53), 1 packet some days, we see a *lot* of this. anyone else seeing similar? randy
Re: Update to BCP-38?
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 > On 5 Oct 2019, at 12:00 am, Stephen Satchell wrote: > > On 10/3/19 10:13 PM, Fred Baker wrote: >> 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Pain Experiment
Matt Harris wrote: That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6. If this is a concern, then get an allocation from your local RIR and announce it yourself. Then no provider lock-in based on address space of any sort. So, IPv6 did not failed, because manual renumbering is easy and, even if it is hard, we don't need CIDER. Very convincing argument. In general any sort of provider move is going to be disruptive if you don't have your own address space, Automatic renumbering is the technology to make it not disruptive. It is doable, if the tricky part of nameserver address changes is properly taken care of. But, people who think renumbering just a prefix change can not do it, resulting in garbages like A6 RRs or IPv6 itself. Masataka Ohta
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Oct, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 775762 Prefixes after maximum aggregation (per Origin AS): 297902 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 373665 Total ASes present in the Internet Routing Table: 65737 Prefixes per ASN: 11.80 Origin-only ASes present in the Internet Routing Table: 56544 Origin ASes announcing only one prefix: 24250 Transit ASes present in the Internet Routing Table:9193 Transit-only ASes present in the Internet Routing Table:274 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 43 Max AS path prepend of ASN ( 19955) 41 Prefixes from unregistered ASNs in the Routing Table:28 Number of instances of unregistered ASNs:36 Number of 32-bit ASNs allocated by the RIRs: 28938 Number of 32-bit ASNs visible in the Routing Table: 23673 Prefixes from 32-bit ASNs in the Routing Table: 108164 Number of bogon 32-bit ASNs visible in the Routing Table:26 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:354 Number of addresses announced to Internet: 2837147776 Equivalent to 169 /8s, 27 /16s and 112 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 258239 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 208891 Total APNIC prefixes after maximum aggregation: 62374 APNIC Deaggregation factor:3.35 Prefixes being announced from the APNIC address blocks: 203429 Unique aggregates announced from the APNIC address blocks:85058 APNIC Region origin ASes present in the Internet Routing Table: 10102 APNIC Prefixes per ASN: 20.14 APNIC Region origin ASes announcing only one prefix: 2803 APNIC Region transit ASes present in the Internet Routing Table: 1498 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5104 Number of APNIC addresses announced to Internet: 767379072 Equivalent to 45 /8s, 189 /16s and 70 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:228287 Total ARIN prefixes after maximum aggregation: 106572 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 226575 Unique aggregates announced from the ARIN address blocks:107903 ARIN Region origin ASes present in the Internet Routing Table:18609 ARIN Prefixes per ASN:12.18 ARIN
Re: IPv6 Pain Experiment
On 10/4/19 7:45 AM, Warren Kumari wrote: On Fri, Oct 4, 2019 at 5:13 AM Masataka Ohta wrote: Doug Barton wrote: And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix. This is the same as saying "If you need to change providers in IPv4, once you have your addressing plan in place all you have to do is change the prefix", or "To build the Eiffel Tower, all you have to do is bolt bits of metal together" -- it's technically correct*, but handwaves away the actual complexity and scale of work. Yes, you (clearly) can renumber v6 networks, and it's *probably* easier than renumbering v4, but "just change the prefix" oversells it. I was assuming that this audience understands the relative complexity of changing the network parts of the address, and leaving the subnet and host parts in place. And by and large, it is not true that you can do this with IPv4. You might occasionally get lucky with it, but that would be the exception, not the rule. As for your Eiffel Tower example, the design and architecture are the pieces that would already be in place as part of your networking plan, so in a sense we're talking about RE-building the Eiffel Tower by taking off one bit of metal (the old network) and bolting another piece in its place. Not building it all over again from scratch. So you can credibly accuse me of underselling the renumbering effort, but don't engage in hyperbole to try to balance the scales. Renumbering has its pain points regardless of the protocol, but if you've designed your network correctly IPv6 renumbering is considerably easier than it is in IPv4. Doug
Re: IPv6 Pain Experiment
On Friday, 4 October, 2019 05:55, "Doug Barton" said: > ... unless you're large enough to have your own address space. And even > if you do need to change providers, once you have your addressing plan > in place all you have to change is the prefix. And if this is hard, we should be beating up hardware (and software) vendors to make it easier. Case in point, my home broadband has a /56 routed to it. (It's a dynamic /56, and it does change, which is broken in itself, but that's another discussion). The ISP-supplied router has a basic GUI-driven IPv6 firewall - in which I can edit only the host parts of the local addresses, and the /64 is automatically filled in from the current prefix. Routed prefix changes, all the firewall rules change to match. I'm not a firewall guy, but wouldn't it be cool if grown-up firewalls did this (if they don't already)? Maybe with a bit more control, so you explicitly set $IPV6_PREFIX somewhere in the config, and can base all your other config off it. Maybe with the ability to have multiple such prefixes active at the same time, so while you're renumbering, your firewall rules, interface addressing, RAs, ... all cover both IPv6 prefixes just by adding one line of config to the "prefixes I have" stanza. Even without the tools built-in, s/2001:db8:1::/2001:db8:2::/g feels like a manageable piece of work, not a blocker. Regards, Tim.
Re: IPv6 Pain Experiment
On Fri, Oct 4, 2019 at 5:13 AM Masataka Ohta wrote: > > Doug Barton wrote: > > > And even > > if you do need to change providers, once you have your addressing plan > > in place all you have to change is the prefix. > This is the same as saying "If you need to change providers in IPv4, once you have your addressing plan in place all you have to do is change the prefix", or "To build the Eiffel Tower, all you have to do is bolt bits of metal together" -- it's technically correct*, but handwaves away the actual complexity and scale of work. Yes, you (clearly) can renumber v6 networks, and it's *probably* easier than renumbering v4, but "just change the prefix" oversells it. > Your attempt to hype people that renumbering were easy has > zero probability of success here. > > > Except that it's not failing, > > It failed from the beginning. W *: Yes, the best kind of correct. > > Masataka Ohta -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: Update to BCP-38?
On 10/3/19 10:13 PM, Fred Baker wrote: > 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.
Re: IPv6 Pain Experiment
On Thu, Oct 3, 2019 at 10:42 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Doug Barton wrote: > > >> Automatic renumbering involving DNS was important design goal > >> of IPv6 with reasons. > >> > >> Lack of it is still a problem. > > > Meanwhile, the thing that most people miss about IPv6 is that except in > > edge cases, you never have to renumber. You get a massive address block > > that you can use as long as you pay your bill. > > That is called "provider lock-in", which is the primary > reason, when IPng WG was formed, why automatic renumbering > is necessary for IPv6. > If this is a concern, then get an allocation from your local RIR and announce it yourself. Then no provider lock-in based on address space of any sort. In general any sort of provider move is going to be disruptive if you don't have your own address space, so that should be taken into account when choosing to use address space that is somebody else's for production services that need to be reachable globally. > So, again, stop spreading FUD. > > Look at the fact that IPv6 failed badly. > Huh? IPv6 has succeeded slowly, not failed badly. There are loads of us using it in production today just fine.
Re: IPv6 Pain Experiment
Doug Barton wrote: And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix. Your attempt to hype people that renumbering were easy has zero probability of success here. Except that it's not failing, It failed from the beginning. Masataka Ohta
