Unix Technical Forum

Re: inet increment w/ int8

This is a discussion on Re: inet increment w/ int8 within the pgsql Hackers forums, part of the PostgreSQL category; --> Patrick Welche wrote: > On Fri, May 20, 2005 at 11:12:54PM -0400, Bruce Momjian wrote: > > Added to ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-11-2008, 05:02 AM
Bruce Momjian
 
Posts: n/a
Default Re: inet increment w/ int8

Patrick Welche wrote:
> On Fri, May 20, 2005 at 11:12:54PM -0400, Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Allow INET + INT4/INT8 to increment the host part of the address, or
> > throw an error on overflow
> >
> > I have not heard any use-case for adding to the network value if INET,
> > and by not using it, we can have an easy operator API.

>
> Thanks - I'll look at the code that was posted..


I modified the TODO. I think we only need an INT4. I realize INT8
would be for IPV6 but I can't imagine a network that has more than INT4
hosts (not part of the network address).

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-11-2008, 05:02 AM
Douglas McNaught
 
Posts: n/a
Default Re: inet increment w/ int8

Bruce Momjian <pgman@candle.pha.pa.us> writes:

> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).


Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host" part of the address (if you're on an Ethernet) is
generally the 64 bit MAC address.

-Doug

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-11-2008, 05:02 AM
Bruce Momjian
 
Posts: n/a
Default Re: inet increment w/ int8

Douglas McNaught wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> > I modified the TODO. I think we only need an INT4. I realize INT8
> > would be for IPV6 but I can't imagine a network that has more than INT4
> > hosts (not part of the network address).

>
> Actually "increment the host address" isn't a well-defined concept for
> IPV6. The "host" part of the address (if you're on an Ethernet) is
> generally the 64 bit MAC address.


So if the network card dies the machine has a new IPv6 address and you
just update your DNS? Do you update your routing tables?

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-11-2008, 05:02 AM
Stephen Frost
 
Posts: n/a
Default Re: inet increment w/ int8

* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Douglas McNaught wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >
> > > I modified the TODO. I think we only need an INT4. I realize INT8
> > > would be for IPV6 but I can't imagine a network that has more than INT4
> > > hosts (not part of the network address).

> >
> > Actually "increment the host address" isn't a well-defined concept for
> > IPV6. The "host" part of the address (if you're on an Ethernet) is
> > generally the 64 bit MAC address.

>
> So if the network card dies the machine has a new IPv6 address and you
> just update your DNS? Do you update your routing tables?


Generally routing isn't done to the last 48 bits (dunno where 64 bit
came from, but MAC's are 48 last I checked .

DNS to that level would need to be changed though, yes.. :/

(I'm not exactly a big fan of this development, in fact, I think it's a
bunch of poo, but then, I don't write the standards).

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCkf/0rzgMPqB3kigRAoAVAKCJzkbXroiEywNzLFlG3GPZE/UpEwCdGSyT
f15hDZsbZBU9XdaD+EBoqj8=
=EZaY
-----END PGP SIGNATURE-----

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 04-11-2008, 05:03 AM
Sander Steffann
 
Posts: n/a
Default Re: inet increment w/ int8

Hi,

>> > I modified the TODO. I think we only need an INT4. I realize INT8
>> > would be for IPV6 but I can't imagine a network that has more than INT4
>> > hosts (not part of the network address).

>>
>> Actually "increment the host address" isn't a well-defined concept for
>> IPV6. The "host" part of the address (if you're on an Ethernet) is
>> generally the 64 bit MAC address.

>
> So if the network card dies the machine has a new IPv6 address and you
> just update your DNS? Do you update your routing tables?


There are standards defined for automatically determining the IPv6 address
of a host (Stateless Address Autoconfiguration). These include a standard
for "Privacy Extensions for Stateless Address Autoconfiguration in IPv6"
where the host-part of the IPv6 address changes over time to make it more
difficult to identify a single user. The net-part of the IPv6 address can be
determined by "Router Advertisements".

By default an IPv6 address is divided as follows:
first 32 bits: ISP
next 16 bits: customer
next 16 bits: subnet
rest (64 bits): host

So an ISP gets a /32 from ARIN/RIPE/LACNIC/APNIC/AfriNIC, which assigns a
/48 to a customer, which assigns a /64 to each separate network. There are
ISPs that have so many customers that they got more than a /32, and if a
customer needs more than 16 bits for subnets they can get a bigger block
than a /48. This addressing scheme means that even a home-user is a customer
and gets a /48 with 16 bits for subnetting. There are discussions going on
about giving home users a /56 block instead, but I haven't heard a final
decision about that yet (in the RIPE region).

From
http://www.tcpipguide.com/free/t_IPv...Mappin g.htm:
The IEEE has also defined a format called the 64-bit extended unique
identifier, abbreviated EUI-64. It is similar to the 48-bit MAC format,
except that while the OUI remains at 24 bits, the device identifier
becomes 40 bits instead of 24. This provides gives each manufacturer
65,536 times as many device addresses within its OUI.

A form of this format, called modified EUI-64, has been adopted for
IPv6 interface identifiers. To get the modified EUI-64 interface ID
for a device, you simply take the EUI-64 address and change the 7th
bit from the left (the "universal/local" or "U/L" bit) from a zero to
a one.

Because the 7th bit is always a one with auto-configuration, addresses with
7th bit zero are still free to be manually assigned.

I hope this helps a little...
Sander.



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:11 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com