Fwd: [jari.ar...@piuha.net: Ray Tomlinson]

[Rich Kulawiec]

Forward from the main IETF mailing list.
Includes comments from Craig Partridge and Vint Cerf.

---rsk

- Forwarded message from Jari Arkko  -

> From: Jari Arkko 
> Date: Sun, 6 Mar 2016 11:02:13 +
> To: IETF 
> Subject: Ray Tomlinson
> 
> I received sad news about Ray Tomlinson?s death from Craig Partridge
> and Vint Cerf yesterday. I wanted to send what they wrote to the IETF
> list as well:
> 
> > I just learned that Ray Tomlinson died this morning.
> > 
> > Ray Tomlinson had been at BBN since 1967.  He?s best known for
> > inventing the concept of sending email over a computer network and
> > choosing the @ sign as the way to split the mailbox name from the host
> > name.  But that?s a fraction of his amazing contributions to our field.
> > Ray was one of a four person team that created TENEX, the first operating
> > system to support virtual memory using paging. He wrote one of the
> > first implementations of TCP and, when he found data being duplicated
> > in the received stream, devised methods to ensure that sequence numbers
> > were not duplicated that remain fundamental to TCP/IP implementations
> > today. He worked on the first object-oriented distributed system and
> > early multimedia email systems.  And I?m sure I?m forgetting at least
> > half a dozen other ways Ray made our world better.
> > 
> > Craig
> 
> > I knew and worked with Ray Tomlinson during the development of
> > the ARPANET and its host protocols and benefited, as have billions,
> > from his seminal work on networked electronic email. More important,
> > from my personal perspective, was his work with Bill Plummer on the
> > first PDP-10 TENEX implementation of TCP (and later TCP/IP). In 1975, he
> > discovered that the TCP as specified in December 1974 had flaws that led
> > it to fail to detect duplicate packets and, together with Yogen Dalal,
> > developed the three-way handshake and initial sequence number selection
> > method to solve this problem. As Craig Partridge summarizes, Ray was a
> > long-time and creative contributor to the Internet, operating systems,
> > and many other highly practical applications in the computer science
> > and communications domains. He was a self-effacing and humble man and
> > extraordinary performer in our online world. I will miss his thoughtful,
> > low-key and always helpful counsel.
> > 
> > vint
> 
> Jari Arkko
> 

- End forwarded message -

Re: Netflix VPN Detection Issues

[Dave Temkin]

Daniel,

I don't see any emails from *.nodesdirect aside from a peering request from
a long time ago. Feel free to email me directly with the IP ranges in
question and I'll make sure they get looked at.

-Dave

On Tue, Mar 1, 2016 at 6:53 PM, Daniel Stephens 
wrote:

> Hello,
>
> Can someone from Netflix contact me off-list to assist in a wrongly
> classified prefix as a VPN/proxy? We serve Internet to a few large
> residential communities and they have been blocked as of yesterday
> afternoon. Attempts to cdnetops@ have been unsuccessful.
>
> Thank you,
>
> Daniel Stephens
>
>

Re: Thank you, Comcast.

[Jay R. Ashworth]

- Original Message -
> From: "Mike Hammett" 

> I think you'd be hard pressed to find more than a tenth of a percent of people
> attempt to run their own DNS server. Some do because they think it'll be 
> better
> in some way. Rare is the occasion where anything user configured would
> outperform a local DNS server managed by the ISP that does no form of 
> trickery.

I suspect it's higher than that, because of the fraction of edge routers which
do DNS masquerading.  Since that caches, I'm assuming it's a recursor, rather
than merely a pass-through, though I suppose it might be implementation 
dependent.

And *most* eyeball customer resolver servers engage in search stupidity now,
don't they? :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: IPV6 planning

[Owen DeLong]

> On Mar 5, 2016, at 13:46 , Mark Tinka  wrote:
> 
> 
> 
> On 5/Mar/16 23:19, Laurent Dumont wrote:
> 
>> Hiya,
>> 
>> We are currently considering deploying IPv6 for a Lan event in April.
>> We are assigned a /48 which we then split into smaller subnets for
>> each player vlan. That said, what remains to be decided is how we are
>> going to assign the IPv6. Basically, it seems that are two ways, one
>> SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6
>> which is basically DHCP but for IPv6.
>> 
>> Large events like Dreamhack have used SLAAC and the feedback has been
>> mostly positive. Can anyone comment regarding past experiences with
>> IPv6 gotchas and things that you don't really expect when running
>> dual-stack on a large-ish network?
> 
> SLAAC is the way you want to do, as DHCPv6 does not give you a default
> gateway.

Though you will inherently get one from the RA packet that tells you to
ask DHCPv6 for information anyway.

> If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
> hybrid of DHCPv6 and SLAAC is reasonable.

Or you can use RFC6106 in your RAs on SLAAC.

Owen

Re: IPV6 planning

[Owen DeLong]

> On Mar 6, 2016, at 17:57 , Baldur Norddahl  wrote:
> 
> Den 6. mar. 2016 13.41 skrev "Karl Auer" :
> 
>> Dunno about "harsh", but RFC 2464, section 4 says that the prefix must
>> be 64 bits. By (extremely strong) implication, a host must not use a
>> prefix of any other length to perform SLAAC. I say "extremely strong"
>> because the entire description of how an IPv6 Ethernet interface
>> identifier is formed depends on it being composed of the prefix plus an
>> EUI-64 identifier. Later RFCs firm up the requirement and apply it in
>> other contexts.
> 
> But the most popular OS (Windows) completely ignores all of that and makes
> up an identifier not based on EUI-64. Everyone are happy anyway. The RFC
> should have let identifier selection as an implementation detail as the
> risk of collision is almost non existent given a sufficient random
> selection and we have duplicate address detection as a safeguard.

To the best of my knowledge, Windows actually generates three addresses…

1. Subnet Stable quasi-randomized address unrelated (or at least not reversable 
to) MAC address.
2. Privacy address which rotates frequently (for some definition of frequently).
3. Stable address related to MAC address.

The 3rd one is standard SLAAC.
The second one is standard privacy extensions.
THe first one is unique to Windows. You’ll get the same address every time you 
connect to the same subnet, but you won’t see that suffix for that host on any 
other subnet.

Owen

Re: IPV6 planning

[Alarig Le Lay]

On Mon Mar  7 15:51:06 2016, Owen DeLong wrote:
> To the best of my knowledge, Windows actually generates three
> addresses…
> 
> 1. Subnet Stable quasi-randomized address unrelated (or at least not
> reversable to) MAC address.
> 2. Privacy address which rotates frequently (for some definition of
> frequently).
> 3. Stable address related to MAC address.
> 
> The 3rd one is standard SLAAC.
> The second one is standard privacy extensions.
> THe first one is unique to Windows. You’ll get the same address every
> time you connect to the same subnet, but you won’t see that suffix for
> that host on any other subnet.

It’s not exactly specific to Windows, dhcpcd use a something like that
(my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

-- 
alarig


signature.asc
Description: Digital signature

Re: IPV6 planning

[Owen DeLong]

> On Mar 7, 2016, at 16:01 , Alarig Le Lay  wrote:
> 
> On Mon Mar  7 15:51:06 2016, Owen DeLong wrote:
>> To the best of my knowledge, Windows actually generates three
>> addresses…
>> 
>> 1. Subnet Stable quasi-randomized address unrelated (or at least not
>> reversable to) MAC address.
>> 2. Privacy address which rotates frequently (for some definition of
>> frequently).
>> 3. Stable address related to MAC address.
>> 
>> The 3rd one is standard SLAAC.
>> The second one is standard privacy extensions.
>> THe first one is unique to Windows. You’ll get the same address every
>> time you connect to the same subnet, but you won’t see that suffix for
>> that host on any other subnet.
> 
> It’s not exactly specific to Windows, dhcpcd use a something like that
> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

Yes, but in the case of Windows, that happens with SLAAC without DHCP.

TTBOMK, this is unique to windows.

Owen

2nd Call - Call for Presentations - CHI-NOG 06

[Tom Kacprzynski]

CHI-NOG 06's deadline for the Call for Presentations is next week, March
15th. Please submit your presentation's abstract at
http://chinog.org/meetings/*chi-nog*-06/abstract-submission/
. All accepted
speakers will receive complimentary registration. Early bird registration
is already open.

The program committee is looking forward to your applications.


Thank you.

Tom Kacprzynski
CHI-NOG PC Chair

-

*Call for Presentations*

*CHI-NOG* 06 - (Chicago Network Operators Group)

May 12th 2016, Chicago, IL

The Chicago Network Operators Group (*CHI-NOG*) is a vendor neutral
organization. Our goal is to create a regional community of network
professionals by presenting the latest technology trends, enabling
collaboration and providing networking opportunities. *CHI-NOG* will be
hosting its sixth annual conference May 12th, 2016 in downtown Chicago. For
more information please see http://chinog.org.

The *CHI-NOG* Program Committee is seeking proposals for presentations on
relevant networking technologies with a focus on the following topics:

* Network Automation/ DevOps
* Interconnection/Peering/Cloud Exchanges
* Low Latency Networks/Financial Networks
* Network Security
* Internet Monitoring
* Advanced BGP/MPLS Technologies
* Software Defined Networking
* Cloud Networking Technologies
* Network Operation
* Academic Research in Networking and Related Infrastructure Fields
* Open Source Networking Tools
* Optical Networking/Data Center Interconnect
* Data Center Fabric
* Wireless
* IPv6


*Session Format*
Each presentation is 30 minutes, which includes a questions and answers.
The duration can be extended per individual request to 60 minutes and will
be considered by the program committee. Presentations should not contain
any marketing material and should avoid discussion of commercial products
but rather focus on the underlying technology.


*Key Dates*
* Presentation Abstract Submission Deadline --- 3/15/16
* Abstract Selection --
3/18/16
* Presentation Full Slides Submission Deadline - 4/15/16
* Final Selection --
4/29/16
* Conference -- 5/12/16


*Submission*
Please submit presentation's abstract proposal by filling out the
submission form at
http://chinog.org/meetings/*chi-nog*-06/abstract-submission/
 . Once your
presentation is selected please provide the program committee with your
photo and a short bio for web publication. All accepted speakers will
receive complimentary tickets to the conference.

The program committee is looking forward to your submission and attendance
at the conference.

Re: IPV6 planning

[Baldur Norddahl]

On 8 March 2016 at 01:01, Alarig Le Lay  wrote:

> It’s not exactly specific to Windows, dhcpcd use a something like that
> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.
>

It appears that RFC 7217 does not actually demand a 64 bit interface
identifier. One could therefore do a non-64 bit RFC 7217 SLAAC on operating
systems that support that.

"We note that [RFC4291] requires that the Interface IDs of all
  unicast addresses (except those that start with the binary
  value 000) be 64 bits long.  However, the method discussed in
  this document could be employed for generating Interface IDs
  of any arbitrary length, albeit at the expense of reduced
  entropy (when employing Interface IDs smaller than 64 bits)."


Regards,

Baldur