Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Suzanne Woolf]

> On Oct 15, 2018, at 10:00 PM, Rodney Joffe  wrote:
> 
> At NANOG two weeks ago, we had an interesting discussion at one of the lunch 
> tables. One of the subjects we discussed was the original IANA, and RFC 
> Editor, Jon Postel.
> 
> Seven of the ten people at the table had never heard of him. Maybe these days 
> it no longer matters who he was, and what he meant to where we are today.
> 
> 
> 
> For those who care about the history of the Internet, and routing and 
> addressing. And protocols…

And the principles  that make it “the Internet”, not just “some internets.”

> 
> https://tools.ietf.org/html/rfc2468
> 



Suzanne

Re: IPv6 automatic reverse DNS

[Suzanne Woolf]

Hi Wes,

> On Oct 29, 2016, at 8:40 AM, Wesley George  wrote:
> 
> 
>> On Oct 28, 2016, at 11:03 PM, White, Andrew  
>> wrote:
>> 
>> There are two competing drafts for synthetic rule-based PTR responses for 
>> IPv6 rDNS:
>> 
>> Howard Lee, Time Warner Cable (now Charter)
>> https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
>> 
>> J. Woodworth, CenturyLink
>> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>> 
> 
> At the risk of getting into IETF administrivia, a little clarification is 
> important here: The first draft you mention above was replaced by the draft I 
> referenced in my previous email. It is currently an adopted WG draft in 
> DNSOP, moving toward working group last call as a consensus document., thus 
> the window for capturing and incorporating feedback is closing soon. The 
> second document does not appear to be associated with any IETF Working Group 
> yet, but it also isn't competing with the first document. The first draft is 
> informational status, discussing the issues and considerations surrounding 
> this problem, of which generating on-the-fly reverse records is one possible 
> solution. The second draft is a proposed standard defining *how* to generate 
> those on-the-fly reverse records assuming one decides that is the right path 
> to take in one's network, and would dovetail nicely via reference to section 
> 2.5 of isp-ip6-rdns.

This is exactly right, and thanks for the clear explanation of arcane IETF 
process….

Comments on https://www.ietf.org/id/draft-ietf-dnsop-isp-ip6rdns-02.txt 
 can go to Lee or 
the WG mailing list, dn...@ietf.org . We’re trying to 
make it useful for operators, so having operators comment is *really* good….

The WG felt quite strongly that the document shouldn’t be prescriptive as far 
as telling people they *should* do this, only some of the considerations about 
doing it if they wish to. 

John Woodworth’s bulk-rr document was discussed in the WG in the last IETF 
meeting (Berlin in July) and got enough interest that John was planning to keep 
working on it. It needs people committed to active review and discussion on it 
to become a WG document, which he hasn’t requested (yet), but if the idea seems 
useful to you, you should tell him.


best,
Suzanne
(DNSOP co-chair, but not speaking for the WG or anyone else….)

Re: Dyn DDoS this AM?

[Suzanne Woolf]

> On Oct 24, 2016, at 12:06 PM, Eitan Adler  wrote:
> 
> On 24 October 2016 at 01:25, LHC  wrote:
>> All this TTL talk makes me think.
>> 
>> Why not have two ttls - a 'must-recheck' (does not expire the record but 
>> forces a recheck; updates record if server replies & serial has incremented) 
>> and a 'must-delete' (cache will be stale at this point)?
> 
> If clients can't get one TTL correct what makes you think they will
> get a more complicated two TTL system correct?
> 

….To say nothing of resolvers that simply ignore server-side TTLs and set their 
own. 

For instance, 
https://www.icann.org/en/system/files/files/rssac-003-root-zone-ttls-21aug15-en.pdf
 

 “RSSAC 003: RSSAC Report on Root Zone TTLs” will tell you far more than you 
really want to know about TTLs and caching behavior, and some of it is specific 
to the root zone, but one of the key observations is "Root zone TTLs appear to 
not matter to most clients.”

Modern large-scale DNS is a fairly complex system. Speculating from here about 
how it behaved under attack in someone else’s network is interesting, and I 
look forward to more information from Dyn as they feel they can share it— but 
DDoS is a big enough fact of life for them and everyone else that if there was 
a simple answer, I think someone would be making a fortune on it already, or at 
least have filed the patents.


Suzanne
(speaking for myself)

Re: IP4 Space - the lie

[Suzanne Woolf]

On Fri, Mar 05, 2010 at 12:39:19PM +, bmann...@vacation.karoshi.com wrote:
   er... what part of dual-stack didn't you understand?
   dual-stack consumes exactly the same number of v4 and v6 addresses.
   
   if you expect to dual-stack everything - you need to look again.
   either you are going to need:
 
   lots more IPv4 space
 
   stealing ports to mux addresses
 
   run straight-up native IPv6 - no IPv4 (unless you need to talk to 
   a v4-only host - then use IVI or similar..)
 
   imho - the path through the woods is an IVI-like solution.

There are several IPv4/IPv6 co-existence technologies under
development that attempt to resolve the asymmetry Bill notes here,
where IPv4 addresses are already scarce and IPv6 addresses may
reasonably be treated as less so. They include IVI, NAT64/DNS64, and
dual-stack lite.

See for example the lightning talk last Wednesday in Austin on AFTR,
ISC's free, open source implementation of dual-stack lite, or the
panel discussion at APRICOT earlier this week.

It's only been in the last couple of years that the IETF and the
vendors have been taking seriously the problem of moving IPv4-IPv6
co-existence mechanisms into the network, away from host-based
dual-stack and into use cases where legacy infrastructure has to
co-exist with the need for growth. But now that they have, there's an
embarrassment of what we can hope turn out to be riches in this
areaor at least a pony amongst the, err, bulk of material.


Suzanne

Re: IP4 Space - the lie

[Suzanne Woolf]

On Sat, Mar 06, 2010 at 02:23:59AM +0800, Owen DeLong wrote:
 
 Owen (who is very glad these are technologies OTHER people will use)
 

:) My point was not really to push a particular technology, although
we believe ds-lite is worth looking at or ISC wouldn't have
implemented and released it. (Among other things it does put the pain
of figuring out deployment in more or less the same place that IPv4
exhaustion will be felt: in service-provider networks that will need
to grow after the end of the unallocated IPv4 without leaving behind
legacy customers.)

My point was more that there *are* alternatives in this space that
didn't exist until fairly recently, there's now a much bigger solution
space for the gap between IPv4 runout and global-scale native IPv6
deployment than maybe people think

But it's going to take some effort to find and use the technology
that's right for you and your network, so start allocating that
resource now if you haven't yet.


Suzanne