JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for IPV6-USERS Archives


IPV6-USERS Archives

IPV6-USERS Archives


IPV6-USERS@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

IPV6-USERS Home

IPV6-USERS Home

IPV6-USERS  June 2007

IPV6-USERS June 2007

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

IPv6, DNS, those pesky EUI-64 numbers and even more troublesome RFC3041

From:

Bob Franklin <[log in to unmask]>

Reply-To:

Bob Franklin <[log in to unmask]>

Date:

Tue, 19 Jun 2007 18:38:33 +0100

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (60 lines)

Hello,

I might be missing something really obvious here, but I can't find 
anything in the archives and don't know of a standard solution.

We are facing a problem that enabling IPv6 on a subnet (which we are only 
doing when it is required and it's limited in scope, so far) instantly 
causes a pile of machines with IPv6 enabled to spring into life and start 
using it.  Of course, this is just what IPv6 was designed to do.

However, we then have a problem of registration which is in two parts.


The first is that of DNS registration - like most people on here I 
suspect, we register a machine in the DNS when we allocate it an IP 
address.  With IPv6 and EUI-64, we aren't really 'allocating' an address 
and a host can start using an unregistered IP address (which isn't the 
'clashing' issue it was in IPv4 but is slightly annoying).  The problem is 
exacerbated with RFC3041 so-called 'Privacy Extensions'.

Does anyone have any suggestions for this?  Is there a feature in BIND or 
some other DNS server we've not come across?


Another problem is that of machines just working.  I know we shouldn't 
rely on not having a valid IP address as a suitable security measure, but 
the fact is that we do (and probably will for a while to come).  We can 
obviously take steps to stop Router Advertisement, but I think it's the 
wrong way to go about things and probably ultimately doomed to fail. 
Besides we're trying to break one of things IPv6 has had designed into it 
as a feature from the word go.

This is actually more complex problem than it first appears because people 
with IPv6-enabled hosts might suddenly gain an IPv6 address without 
knowing and find themselves visible in a whole different address space 
(with different firewall rules) and so could be accessing services (and 
being accessed) via means they were unaware of.

In fact, it is an even more complex problem than that was we use 
multinetting with a combination of private (RFC1918) and public IPv4 
addresses as a [not exactly satisfactory] way of keeping internal-only 
hosts hidden from the internet, as well as attempting to alleviate our 
public IP address shortage.  With IPv6 enabled, a device can be visible 
with a public address in IPv6 but a private address in IPv4 with the 
mistaken belief only the latter is active.


Of course, the correct solution here is to disable the IPv6 services on a 
host but, being realistic, users tend to plug things in and only seek 
assistance when things don't work.

Thanks for any assistance in advance,

   - Bob


-- 
  Bob Franklin <[log in to unmask]>              +44 1223 748479
  Network Division, University of Cambridge Computing Service

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
February 2024
December 2023
October 2023
September 2023
June 2023
May 2023
March 2023
January 2023
December 2022
November 2022
June 2022
May 2022
December 2021
April 2021
March 2021
February 2021
December 2020
October 2020
October 2019
August 2019
March 2019
November 2018
August 2018
July 2018
March 2018
February 2018
November 2017
August 2017
June 2017
May 2017
April 2017
January 2017
November 2016
October 2016
September 2016
June 2016
May 2016
January 2016
December 2015
November 2015
October 2015
September 2015
July 2015
October 2014
November 2013
October 2013
August 2013
June 2013
March 2013
February 2013
September 2012
August 2012
July 2012
June 2012
April 2012
February 2012
December 2011
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
February 2010
January 2010
December 2009
November 2009
February 2009
December 2008
November 2008
July 2008
June 2008
May 2008
January 2008
December 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
March 2007
2006
2005
2004
2003
2002
2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager