Senin

IPduh - The Internet Tools




IPduh.com   About   IPduh Internet Tools   Propaganda




IPduh is a set of Internet Forencics and Troubleshooting Tools made to work Together.   IPduh may be used as an Internet Forensics Search Engine or a General Purpose Search Engine.   Smart Humans and Aliens researching the internetz on Earth Love IPduh.






ip    Tools Menu

IP address verbose report




input:



an IPv4 address in dot-decimal notation



output:

For non public, special IP addresses a short explanation and a URI to more information.



xor



For public and special public IP addresses:


  1. The IANA designation of the /8 block containing this IP address.

  2. The Internet Regional Registry of this IP address.

  3. The Autonomous System Path.

  4. The IP Prefix.

  5. The Autonomous System Number.

  6. The Organization using this IP address.

  7. The country or city of the organization to which this IP address is assigned.



    Sometimes the machine(s) using this IP address happen to be in the same country or city.



    The geographical coordinates of the country or the city.



    Two Databases made by IPduh and the MaxMind database are used to determine the geographical location of the IP address. The databases made by IPduh are based mostly on data provided by the Regional Internet Registries. A macro view of the IPduh Country database used is available.



    The physical location of the machine(s) using this IP address is not guaranteed to be the same as the location suggested by IPduh .

  8. The name of the IP address ( known as Reverse DNS record ).

  9. The A record of the IP address name.

  10. The registered domain name associated with the IP address name.

  11. The A records registered domain name.

  12. The dot-decimal IP address entered as a 32b Base 10 Integer.




Examples of using ip with GET requests








ip/dnstrace    Tools Menu




input:



A pubic IPv4 address



output:

The delegation path from the root Name Servers to the Authoritative DNS Netwok Servers of the PTR.



Examples of using ip/dnstrace.








ipv6/dnstrace    Tools Menu




input:



A pubic IPv6 address



output:

The delegation path from the root Name Servers to the Authoritative DNS Netwok Servers of the IPv6 address PTR.



Examples of using ip/dnstrace.








ip/tor-exit    Tools Menu




input:



A unicast IPv4 address



output:


  1. If the IPv4 address entered is listed on the IPduh Tor Exit List, the first and the last times it was seen used as a Tor Exit.

  2. If the IPv4 address entered is listed on the tor.dan.me.uk DNSBL ( a list of currently used Tor Exits ), some information regarding its Tor Network characteristics.



The lookups performed by ip/tor-exit are performed by ip/dnsbl as well.



Examples of using ip/tor-exit.








dns/list    Tools Menu

Create a List of DNS names




input:



DNS names



ipduh-list built-in variables and punctuation marks:

&list=   ---   ,   &title=   ;   &www=1   &sc=1   &sa=1



comments:

All listed strings of characters not Identified by dns/list as DNS names are printed.

A ; stops list processing and hides all characters following it.



output:

A list of DNS names along with links to the appropriate IPduh tools and the URL producing the list.



Examples of using dns/list.








ip/list    Tools Menu

Create a List of IP numbers




input:



IP numbers:

[ IPv4 address | IPv6 address | IPv4 CIDR block | IPv6 CIDR block | Autonomous System Number ]



ipduh-list built-in variables and punctuation marks:

&list=   --   ,   &title=   ;



comments:

All listed strings of characters not Identified by ip/list as IP numbers are printed.

A ; stops list processing and hides all characters following it.



output:

A list of IP numbers along with links to the appropriate IPduh tools and the URL producing the list.



Examples of using ip/list.








IPduh List Syntax    Tools Menu   about ip/list   about dns/list   about demux/list


IPduh list syntax is used to create lists with ip/list , dns/list , and demux/list and it is a simple way of denoting lists in a form text area or a URL.



HTML tags are not allowed.

URL Enconding and URL decoding are handled by the list tools.







Every list item not identified as an IP number by ip/list , a DNS name by dns/list , and an IP number or a DNS name or a URI by demux/list will be printed without IPduh links. This way comments and almost empty lines may be put in a list.

eg:http://ipduh.com/dns/list/?&list=`---google.fr---Google in French---.---google.gr---Google in Greek---'





ipv6/dnstrace    Tools Menu




input:



A pubic IPv6 address



output:

The delegation path from the root Name Servers to the Authoritative DNS Netwok Servers of the IPv6 address PTR.



Examples of using ip/dnstrace.








dns/trace    Tools Menu




input:



A DNS domain name



output:

The delegation path from the root Name Servers to the Authoritative Name Servers of the DNS name.



Examples of using ip/dnstrace.








ipv6/cidr    Tools Menu




input:



An IPv6 CIDR block in CIDR notation



output:


  1. Whether the IPv6 CIDR block entered is valid.

  2. If the IPv6 CIDR block entered is invalid a correction is attempted.

  3. The Type of the IPv6 network address.

  4. The IPv6 Range. Network Address - Broadcast Address.

  5. The Number of IPv6 addresses in the CIDR block.




Examples of using ipv6/cidr








ipv6/traceroute    Tools Menu




input:



An IPv6 address



output:

If the IPv6 address entered is a routable Unicast Internet IPv6 address, the intermediate routers along the path from an IPduh Internet Host to the Internet host using the IPv6 address entered. For each of the routers in the path ipv6/traceroute attempts to output their reverse records, their IPv6 addresses, the Autonomous Systems in which they belong, and the time it took them to respond to the traceroute probes.







ipv6    Tools Menu

IPv6 address basic information lookup




input:



An IPv6 Address



output:


  1. The type of the IPv6 address entered, URIs to more information and the appropriate RFC, if needed.

  2. Allocation Prefix , Status , Responsible RIR , Allocation Date.

  3. The short form of the IPv6 address entered.

  4. The long form of IPv6 address entered Hexadecimal and Binary.

  5. The unsigned integer number represantating the IPv6 address entered.

  6. The Country in which the Organization using this IPv6 address is located.



    The machine(s) using this IPv6 address may not be on the same country.



    The Location is determined by the Regional Internet Registries data and a macro view of the IPv6 addresses per country is also available.




Examples of using ipv6.








as/prefix    Tools Menu

IP prefixes originating an Autonomous System




input:



An Autonomous System Number



output:

The IP prefixes originating the autonomous system



Examples of using as/prefix.




Still in Beta release --Not consistent Results.



Glitch - Bug: If you get "I did not find IP prefixes originating from 'AS#'" for an autonomous system number with prefixes in the IPduh Database, try to refresh the page.







ipv6/whois    Tools Menu

IPv6 address whois information lookup




input:



An IPv6 Address



output:

For non Global Unicast IPv6 addresses,



a short explanation and a URI to more information or the apprpopriate RFC.



For Global Unicast IPv6 addresses,


  1. The parent IANA block.

  2. The IANA status.

  3. The Regional Internet Registry.

  4. The whois server.

  5. The whois information for the owner of the block.




Examples of using ipv6.








ipv6/ptr    Tools Menu

IPv6 address PTR ( Reverse DNS name ) lookup




input:



An IPv6 address



output:

The PTR of the IPv6 address entered.



Examples of ipv6/ptr.








ip/ptr/24    Tools Menu

The PTR of all IP addresses in a /24 network




input:



A pubic IPv4 address or a /24 CIDR or the three first Bytes of an IP address in decimal dotted notation



output:

The PTR ( Reverse DNS names ) for all the IP addresses in the /24 ( C ) Network along with pointers to more information.



Examples of using ip/ptr/24 .








idn/ace    Tools Menu

IDNA - Unicode to ACE convertion




input:



An International Domain Name in Unicode.



output:

An ASCII Comptible Encoded string of characters.



Examples of using idn/ace.








idn/unicode    Tools Menu

IDNA - ACE to UNICODE convertion




input:



An International Domain Name in ASCII Compatible Encoding ACE.



output:

The International Domain Name in Unicode.



Examples of using idn/unicode.








pdb/as    Tools Menu

PeeringDB information about an Autonomous System




input:



An autonomous system number



output:

The information that the Autonomous System Owner put in the Peering database.


The peeringdb information is cached for at least 15 days. The latest PeeringDB information can be viewed at peeringdb.com.



Examples of using pdb/as.








ip/whois    Tools Menu

IP address whois lookup




input:



a public IPv4 address



output:

The whois information for the IP address entered.





Examples of using ip/whois with GET requests





Caveat


ip/whois caches whois information for 15 days.





idn    Tools Menu

International Domain Name convertions ( Unicode to ACE xor ACE to Unicode )




input:



a Domain Name



output:

If the domain entered is an international domain name encoded in Unicode it's ASCII Compatible encoded ( ACE ) version.

If the domain name entered is an Internation domain name encode in ACE it's equivalent Unicode encoded version.



Examples of using idn.








ip/whois/as    Tools Menu

Autonomous System Number whois lookup




input:



an Autonomous System number

an Autonomous System number with the "AS" prefix

an Autonomous System number with the "ASN" prefix.



output:

The whois information for an Internet Autonomous System.



If the Autonomous System Number entered is not used in Internet BGP routing an explanation is attempted.





Examples of using ip/whois/as with GET requests








ip/cidr    Tools Menu

IP CIDR Calculator




input:



A network block in CIDR notation



output:


  1. If the network address on the CIDR is valid and the network mask on the CIDR is valid. Each Byte in the network address in Binary (put your cursor above the network address on the CIDR block)

  2. If the CIDR block is invalid ( the network address is not compatible with the network mask ) a valid CIDR block is suggested.

  3. The IP Range. Network Address - Broadcast Address.

  4. The Network Mask in decimal dotted notation and each Byte in binary ( put your cursor above the mask).

  5. The Number of IP addresses in the network block.

  6. If the the CIDR block is in a special block a short explanation and URI to more information, usually the appropriate RFC.




Examples of using ip/cidr with GET requests








ip/reverse or ip/ptr   Tools Menu

IP address PTR RR lookup - IP reverse mapping - reverse IP address DNS lookup



ip/reverse or ip/ptr is based on a IP PTR RR lookup also known as reverse DNS lookup and it is usefull in associating an IP address with a host name or a DNS name.



input:



a public IPv4 address



output:


  1. The IP PTR resource record.

  2. The registered domain name -deduced by the PTR record.

  3. The A records of the registered domain name.




Note


For single IP addresses ip output includes the ip/reverse output as well.





Examples of using ip/reverse with GET requests








epoch    Tools Menu

Epoch Clock and Epoch to Date Conversion




input:



An Epoch -an integer number



output:


  1. The equivalent UTC Date.

  2. The Δsec since the Unix Epoch.

  3. The Δsec from the Unix epoch timestamp entered.




Examples of using epoch.









url/bouncer    Tools Menu

Bounce URLs - Basic Protection against Malicious URLs




input:



[ IPv4 address | IPv6 address | URI | DNS name ]



output:

The Bouncer will lookup the DNS name or the IP address contained in the URI in a few major Black Lists. If the URI , IP address , or DNS name pass the test , the bouncer will redirect you there after a few seconds.




The Bouncer transforms plain DNS names , plain IPv4 addresses , and plain IPv6 addresses to HTTP URLs.



The Bouncer will bounce URIs using the protocols used often with web browsers: HTTP , HTTPS , and FTP.



The Bouncer runs a basic test against the host you are destined.

For a more thorough test consult dns/bl for domain names and ip/dnsbl for IPv4 address.



The Bouncer is ideal when you need to link to URIs beyond your control or to hide your referrer.



Examples of using url/bouncer.




The Bouncer waits for 4.5 sec before redirecting.

If you do not like the 4.5 sec wait time before the redirection you may use one of the following:

/url/bouncer/1

/url/bouncer/2

/url/bouncer/3

/url/bouncer/4





/url/bouncer/1 waits 0.5 sec before redirecting and it may be used in the same way.

eg:http://ipduh.com/url/bouncer/1/?http://alog.ipduh.com



/url/bouncer/2 waits 1.5 sec before redirecting and it may be used in the same way.

eg:http://ipduh.com/url/bouncer/2/?http://alog.ipduh.com



/url/bouncer/3 waits 2.5 sec before redirecting and it may be used in the same way.

eg:http://ipduh.com/url/bouncer/3/?http://alog.ipduh.com





url/encode    Tools Menu

Percent Encode a URI




input:



A URI



output:

A percent-encoded URI.


Examples of using url/encode.









ip/dnsbl    Tools Menu

IP address Blacklist check.




input:



a public IPv4 address



output:


  1. The answer for this IP address from each of the major IP DNS BlackLists and IP 'black' lists queried.

  2. An explanation for each answer and if needed a URI to more information.








DNS BlackLists and IP 'black' lists queried by ip/dnsbl



  1. ZEN - zen.spamhaus.org

    ZEN combines all Spamhaus IP DNSBLs.




    1. Spamhaus Block List - SBL - sbl.spamhaus.org

      A database of IP addresses of spam-sources, spam support services, and snowshoe spammers ( the CSS component ).

    2. Exploits Block List - XBL - xbl.spamhaus.org

      XBL includes CBL and a customized NJABL




      1. Composite Blocking List - CBL - cbl.abuseat.org

        CBL lists IP addresses exhibiting characteristics which are specific to open proxies, spam bots, and spam malware.

      2. Not Just Another Bogus List - NJABL - njabl.org

        An IP database of known and potential spam sources ( open relays, open proxies, open form to mail HTTP gateways, dynamic IP pools, and direct spammers )



    3. Policy Block List - PBL - pbl.spamhaus.org

      A database of end-user IP addresses which should not be delivering unauthenticated SMTP email to any Internet mail server.

      Many ISPs participate in the PBL project. The PBL lists both dynamic and static IP addresses which by policy whether the block owner's or -interim in its absence- Spamhaus' policy) should not be sending email directly to the MX servers of third parties.



  2. SORBS - dnsbl.sorbs.net

    Contains all the SORBS DNSBLs




    1.   http.dnsbl.sorbs.net

      List of Open HTTP Proxy Servers.

    2.   socks.dnsbl.sorbs.net

      List of Open SOCKS Proxy Servers.

    3.   misc.dnsbl.sorbs.net

      List of open Proxy Servers not listed in the SOCKS or HTTP lists.

    4.   smtp.dnsbl.sorbs.net

      List of Open SMTP relay servers.

    5.   web.dnsbl.sorbs.net

      Hosts that have abusable vulnerabilities

    6.   spam.dnsbl.sorbs.net

      List of hosts that have been noted as sending spam/UCE/UBE to the administrators of SORBS. This zone also contains net blocks of spam supporting service providers, including those who provide web sites, DNS or drop boxes for a spammer. Spam supporters are added on a 'third strike and you are out' basis, where the third spam will cause the supporter to be added to the list.

    7.   block.dnsbl.sorbs.net

      List of hosts demanding that they never be tested by SORBS.

    8.   zombie.dnsbl.sorbs.net

      List of networks hijacked from their original owners, some of which have been used for spamming.

    9.   dul.dnsbl.sorbs.net

      Dynamic IP Address ranges (NOT a Dial Up list!)

    10.   badconf.rhsbl.sorbs.net

      List of domain names where the A or MX records point to bad address space.

    11.   nomail.rhsbl.sorbs.net

      List of domain names where the owners have indicated no email should ever originate from these domains.



  3. SpamCop Blocking List - SCBL - bl.spamcop.net

    SCBL lists IP addresses that were used to spam.

  4. Barracuda Reputation Block List - BRBL - b.barracudacentral.org

    Lists IP addresses which are sending spam or viruses

  5. Tor.dan.me.uk - dan.me.uk - A list of IP addresses used currently by the Tor Network.

    If the IPv4 address entered is listed on tor.dan.me.uk some information regarding its Tor Network characteristics ( the node name, the port used by Tor, and whether it is: Fast,Guard,Named,Running,Stable, or Valid ).

  6. Team Cymru Full Bogons List - Team Cymru

    This List contains IP addresses that are not assigned to an ISP or other end-user and they should not be seen in the Internet.

  7. IPduh Black List - An IP black List, not a DNSBL.

    Contains IP addresses used by abusive or compromised systems.

  8. IPduh Tor Exit List - A list of IP addresses that have been Tor Exits, not a DNSBL.

    This list is maintained by IPduh and it is composed mainly by the Tor Project data .

    If the IPv4 address entered is listed on the IPduh Tor Exit List the first and the last times it was seen used as a Tor Exit are displayed.




Examples of using ip/dnsbl








ip/srv    Tools Menu



Check which of the most common services are running on the host(s) using a remote IP address.




input:



a public IPv4 address



output:


  1. The TCP ports that accepted connection within 300ms.

  2. Limited software recognition for the daemons found listening and some of the headers.

  3. Limited OS recognition, Uptime guess, Link Type Guess, and TOS.

  4. Guess the number of systems using the IP address.




List of the TCP ports probed by ip/srv and their common use



  1. 21 - FTP - File Transfer Protocol

  2. 22 - SSH Secure SHell

  3. 23 - Telnet

  4. 25 - SMTP - Simple Mail Protocol



  5. 465 - SMTP SSL/TLS - Simple Mail Transfer Protocol over SSL/TLS (encrypted)

  6. 53 - DNS - Domain Name System

  7. 80 - HTTP - HyperText Transfer Protocol

  8. 110 - POP3 - Post Office Protocol version 3

  9. 123 - NTP - Network Time Protocol

  10. 143 - IMAP - Internet Message Access protocol

  11. 993 - IMAP over SSL/TLS (encrypted)

  12. 389 - LDAP - Lightweitght Directory Access Protocol

  13. 443 - HTTPS - HyperText Transfer Protocol Secure (encrypted)

    ip/srv also attempts to print the certificate details.

  14. 587 - MSA - Message Submission Agent

  15. 1352 - Lotus Notes

  16. 1433 - Microsoft SQL server

  17. 3306 - MySQL Server

  18. 3389 - Windows Remote Desktop Connection Service






IPduh.com/ip/srv bot


ip/srv bot is called the piece of software that does the scans or looks up the cashed scans. The scans are cashed for no fixed periods of time. The ip/srv bot always attempts to pass the asker's IP address to the web server listening on the scanned IP when it attempts a new (non-cached) scan. The ip/srv bot always acts at someone's request and never picks arbitrary hosts to lookup.



If you are a server administrator who does not want his server's IP to be scanned by ip/srv please tell IPduh so. If you are a server administrator that wants to know who requested an ip/srv scan, search your web server's logs for IPduhSrvBot.



The ip/srv agent signature on http daemons listening on port 80 or port 443 looks like:



"Mozilla/5.0 (compatible; IPduhSrvBot/VERSION; for/192.0.2.222; +http://ipduh.com/about/#ip-srv-bot)"



where: 192.0.2.222 is the IP address of the IPduh user who requested the first ip/srv scan, and VERSION is [0.0.1 - 0.9.9].







dns/whois    Tools Menu

Domain Name whois lookup




input:



a registered DNS domain name



output:


  • The domain name whois information or a URI to the whois information.




Examples of using dns-whois









Caveat


In an effort to not be a nuisance to the whois servers dns/whois caches whois queries for at least 15 days.





dns/bl    Tools Menu

Domain name URIBL and IP BLack List lookup



input:



a DNS domain name



output:


  • The URI Black Lists' answers, and the answers of the major IP (DNS) Black Lists for all the IP addresses DNS related to the domain name.




The URI Black Lists



  1. Google Safe Browsing - Google Safe Browsing FAQ



    This is a list of sites involved in phising or sites dedicated to the spread of malware.

  2. URIBL - uribl.com



    URIBL lists domain names found in URIs in the body of spam messages. These domain names may be used in one or more of the following categories of web sites: spamadvertized sites that are trying to sell something, phising sites, sites that host malware or used by malware, sites that infect visitors with malware.



The IP Black Lists


The IP Black Lists queried for every DNS related IP address are the same with the ones queried by ip/dnbl.



Examples of using dns-bl




For each of the DNS related IP addresses of the domain name dns/bl does not print IP Black Lists that answered "not listed".

You could use dns/bl/verbose if you want to see everything printed.



The domain names listed in the URI Black Lists are: dedicated to the propagation of malware, used for phising, used for spamming, or advertized though spamming.



IPduh suggests to not use your browser to visit any of the domain names listed on the URI Black Lists.



phishing site: Forgery or imitation of another website, designed to trick users into sharing personal or financial information. Entering any personal information on such site may result in identity theft or other abuse of the information entered.



malware site: A site that contains malicious software that could be downloaded to a user's computer without the user's content. A site used in controlling infected computers and coordinate malicious attacks or attempts to spread software viruses and other malicious software.


It is possible for the lists used by dns/bl to contain outdated or false information. It is possible that the lists compiled by IPduh to contain errors. The IPduh experience shows that the external lists chosen and the lists compiled by IPduh have a low false/positive ratio.





dns    Tools Menu

Lookup the A, MX, NS, SOA DNS records, relevant IP addresses, and servers' locations.




input:



a DNS name



output:


  1.  The purpose and the country (if any) of the Top Level Domain TLD.

  2.  The Address ( A ) records and the locations of these IP addresses.

    The A records usually point to webservers.

  3.  The A record of www --The www subdomain usually points to webservers.

  4.  The CNAME record

  5.  The DNAME record

  6.  The AAAA record(s)

    IPv6 address records.

  7.  The TXT record

  8.  The Mail Exchange ( MX ) records, their priority and their location.

    The MX records point to Mail Transfer Agents - mailservers. The number in front of the MX records specifies the preference value for the mailserver or the array of mailservers the record points to.

  9.  The Name Server ( NS ) records and the nameservers' locations.

  10.  The Start Of Authority ( SOA ) record, which includes:




    1.   SERIAL - the domain serial number.

      This is an unsigned 32 bit integer that must be incremented on the primary server every time a change is made. [RFC1912 2.2] recommends the YYYYMMDDnn syntax where YYYY=year,MM=month,DD=day,nn=revision number.

    2.   MNAME - the primary name server.

    3.   RNAME - the email of the domain name administrator.

      RNAME must follow the hostmaster.example.tld format meaning hostmaster@example.tld.

    4.   REFRESH -the refresh timer.

      A signed 32 bit integer that specifies the number of seconds between the time that a secondary name server checks if the zone was changed on the primary nameserver.

    5.   RETRY - the retry timer.

      A signed 32 bit integer that specifies the number of seconds that the secondary name server(s) have to wait if a REFRESH fails.

    6.   TTL - the Time To Live timer.

      TTL is an unsigned 32 bit integer that defines the number of seconds that a record may be cached.








Examples of using dns with GET requests







Note


For better results use the registered domain name example.com and do not use subdomains like www.example.com



There are cases that subdomain zones are delegated to name servers different than the domain authoritative name servers, and the subdomain has a different set of DNS records.




To see the root nameservers for a Top Level Domain use "TLD." and not just "TLD"




For International Domain Names, just use their UTF8 encoded form







ip/traceroute    Tools Menu

IP traceroute



Trace packets on their route from an Internet host in AS2490 along their route to another IPv4 Internet host.



input <



An Internet IPv4 address



output >

If the IP address entered is a routable Internet IP address, the intermediate routers along the IP path from IPduh to the IP address entered. For each of the routers in the path ip/traceroute attempts to output their reverse records, their IP addresses, the Autonomous Systems in which they belong, and the time it took them to respond to the traceroute probes.





anonymity-check    Tools Menu


The anonymity-check shows what a web server can see or deduce about a web user. The web user information leaked to the WWW servers varies and depends on the web user's system, browser, settings, and local or proxy network. Even though the anonymity-check was intended to be used as a tool to demonstrate ways used by many sites to track web users, to check the anonymity of a connection through an HTTP proxy , check the integrity of an HTTP conversation, and test a Tor setup , it is more commonly used to find out the browser and network settings when troubleshooting. The anonymity checker is also a good way to find out if your privacy plugin conceals or ruins your Privacy.



Anonymity-check performs a plethora of tests and it is enhanced with new tests at a regular basis.

For the most part it reports only its finds.



Some of the Anonymity-check checks:


  1. Searching the HTTP headers for proxy traces.



    Some common HTTP headers used by web proxy servers are the following.




    1. HTTP_FORWARDED

    2. HTTP_X_FORWARDED_FOR

    3. HTTP_VIA

    4. HTTP_PROXY_CONNECTION

    5. HTTP_PROXY_ID

    6. HTTP_XROXY_CONNECTION

    7. HTTP_PROXY_CONNECTION

    8. HTTP_CLIENT_IP



  2. If cookies are accepted,anonymity-check processes the *leg cookies which hold information about the client's earlier visits and the previous IP address.

  3. The anonymity checker attempts to virtually ( it does not really store any of your inforamtion to the IPduh systems ) track you through an ETag.

  4. If Java is enabled, anonymity-check attempts to figure out your private IP address along with your computer's host name. None of this information is sent back to IPduh.

  5. Anonymity-check looks at the IP packets coming from your system or proxy system. This way it attempts to find out the MTU and advertised MSS along with information about your OS, your uptime, whether you are behind a NAT router or a firewall, your link type, and the number of the intermediate routers.

  6. Anonymity-check attempts to print the referral URI and the visiting system's host name as seen in the HTTP headers.

  7. Anonymity-check shows a report about your public IP addess. This report contains the same information with ip.

  8. Anonymity-check prints your user agent information as seen in the HTTP headers.

  9. Anonymity-check attemps to figure out the language(s) set to default on your web browser.

  10. If javascript is enabled on your browser, anonymity-check

    1. prints the cookies set by IPduh

    2. the visiting system's screen dimensions

    3. the character string identifying your WWW user agent.

    4. the plugins installed on the web browser, if any

    5. the operating system and the operating system vendor if available

    6. Attempts to store information about your visit on your system.

    7. If the Flash plugin is installed and enabled the anonymity checker attempts to store information about your visit on the Flash Local Share Object.

    8. Attempts to find previously stored information about your visits on your system.



  11. The Anonymity checker attempts to find the cashing name servers used by your system and print links to more information about them.

  12. The Anonymity checker attempts to detect anomalies such as missing or extra headers and HTML injections in the HTTP conversations between you system and IPduh.




Note


To see all the anonymity-check finds visit it two times in a browsing session, then do what you usually do when you want to clean up your browsing history and visit the Anonymity Checker again.

To encrypt your communication with the anonymity checker use https://ipduh.com/anonymity-check.



To use TLS - SSL encryption in between your browser and IPduh you may need to trust the IPduh Certificate Authortity - install the IPduh CA public certificate.

To automate your public IP address lookup you could use http://ipduh.com/my/ip.

Most privacy and anti-tracking Firefox plugins tested against the anonymity-check, so far ( 1330538493 ), failed to deliver what they promise. Actually, 90% of them are completely useless or do Privacy Concealing like it is 1996.





my/geoloc    Tools Menu

geographical location



Yet another HTML5 Location Aware Browsing Demo. Let Google Location Services to estimate your geographical location and draw it on a map.


Before using my/geoloc your browser should ask you if you would like to share the geographical estimation of your system and your IP address with the browser's location service provider --Usually Google Location Services. Your IP address, your GPS reading (if any), and a unique ID identifying your web browser are sent to the location service provider. In case of Google Location Services a cookie with the name PREF is stored in your browser's cookie jar.





demux    Tools Menu

Submit a string of characters to an appropriate IPduh tool




input:

A string of characters:

[ IP address | IP CIDR block | IPv6 address | IPv6 CIDR block | Autonomous System Number | DNS name | URI ]



output:

The string of characters submitted to Demux is submitted to an appropriate IPduh tool.

[ ip | ip/cidr | ipv6 | ipv6/cidr | ip/whois/as | dns | url/decode]



Examples of using demux








demux/class    Tools Menu

Classify a string of characters and see the appropriate IPduh links




input:

A string of characters:

[ IP address | IP CIDR block | IPv6 address | IPv6 CIDR block | Autonomous System Number | DNS name | URI ]



output:

A classification and appropriate IPduh links to further information about the string of characters submitted given.




Examples of using demux/class








demux/list    Tools Menu

Create a List of IP numbers, DNS names, and URIs




input:



listed items:

[ IPv4 address | IPv6 address | IPv4 CIDR block | IPv6 CIDR block | Autonomous System Number | DNS names | URI ]



ipduh-list built-in variables and punctuation marks:

&list=   ---   ,   &title=   ;



comments:

All strings of characters not Identified by demux/list as IP numbers, DNS names, or URIs are printed without IPduh links.

A ; stops list processing and hides all characters following it.



output:

A bookmarkable list of DNS names, IP numbers, URIs and your comments along with links to the appropriate IPduh tools.



Examples of using demux/list





Note


-- is not a valid delimeter anymore. Use , or --- instead. Lists using -- may be compiled by http://ipduh.com/demux/list/old.



There is a 3KB limit on the size of the demux lists.



Through Bouncer URLs are printed only for HTTP , HTTPS , and FTP URIs.





apropos    Tools Menu    apropos guides    add apropos to your browser

Apropos will submit any string of characters to the appropriate IPduh tool.



Apropos may be used as an Internet Forensics Search Engine or a General Purpose Search Engine. Apropos is a good place to start your research and the most commonly used Tool of IPduh.



input:

Any string of characters





output:

The string of characters submitted to apropos will be submitted to the appropriate IPduh tool.

[ ip | ip/cidr | ipv6 | ipv6/cidr | ip/whois/as | dns | url/decode | torrent search | search ]



Examples of using apropos




Note: apropos does not handle IPduh lists ( ip/list , dns/list , demux/list )



apropos guides






Add Apropos to your Browser:



You can add apropos to your browser search engines or set it as your default search engine.



Add Apropos to Mozilla Firefox and Mozilla based browsers

Add Apropos to Chrome

Add Apropos to Internet Explorer

Add Apropos to Opera








To add Apropos to your Mozilla Firefox Search Engines:



Add the Firefox IPduh Apropos add-on from https://addons.mozilla.org/addon/ipduh-apropos/



OR



Click on this



OR


  • visit IPduh

  • click on the down arrow used to select search engine

  • click on Add IPduh Apropos.






To set Apropos as the default search engine used for invalid URLs on Firefox and Mozilla Based Browsers ( Iceweasel , Seamonkey , etc ):


  • Enter about:config in the browser location bar.

  • Promise, you 'll be carefull.

  • Enter keyword.URL in the Filter: under the location bar.

  • Double-click on the keyword.URL result.

  • Enter http://ipduh.com/apropos/? in the text box that pops up

  • OK and close the about:config tab.







To add IPduh Apropos to your Search Engines on Chrome Based Browsers:



Click on this



To set IPduh Apropos as your default search engine on Chrome Based Browsers:


  • visit IPduh

  • Click the Wrench

  • Click Settings

  • Choose IPduh Apropos from the drop down list in the Search section under "Set which search engine is used when searching from the omnibox"





In Chrome's omnibox and when Apropos is set as the search engine used on the location bar, you can differentiate domain names you want to lookup from domain names you want to visit by prepending !d to your query eg: http://ipduh.com/apropos/?!d bing.no. You can also differentiate URIs you want to visit from URIs you want to decode and analyse by prepending !u to the ones you want to analyze, and jump to a Torrent Search by prepending !t to your query.


To add IPduh Apropos to your Internet Explorer Search Engines:



Click on this



OR






  • visit IPduh

  • click on the down arrow used to select search engine

  • click on Add Search Providers.

  • click on IPduh Apropos.







To add IPduh Apropos to your Opera Search Engines:


  • visit IPduh

  • click on the down arrow used to select search engine

  • click on Manage Search Engines.

  • click the Add... Button.

  • set the Name -- Apropos.

  • set the Keyword -- a.

  • set the address to http://ipduh.com/apropos/?%s

  • The check boxes following are optional.

  • Hit OK







You can add Apropos over an encrypted connection to your Browser search engines.



Add Apropos over HTTPS to Mozilla Firefox and Mozilla based browsers

Add Apropos over HTTPS to Chrome

Add Apropos over HTTPS to Internet Explorer

Add Apropos over HTTPS to Opera








To add Apropos over HTTPS ( an encrypted connection ) to the Mozilla Firefox Search Engines:



add the Firefox IPduh Apropos SSL add-on from https://addons.mozilla.org/en-US/firefox/addon/apropos-ssl/



OR


  • visit IPduh Privacy

  • click on the down arrow used to select search engine

  • click on Add IPduh Apropos SSL.






To set Apropos over SSL as the default search engine used for invalid URLs on Firefox and Mozilla Based Browsers ( Iceweasel , Seamonkey , etc ):


  • Enter about:config in the browser location bar.

  • Promise, you 'll be carefull.

  • Enter keyword.URL in the Filter: under the location bar.

  • Double-click on the keyword.URL result.

  • Enter https://ipduh.com/apropos/? in the text box that pops up

  • OK and close the about:config tab.







To set IPduh Apropos over SSL as your default search engine on Chrome Based Browsers:


  • visit the IPduh privacy page.

  • Click the Wrench

  • Click Settings

  • Choose IPduh Apropos SSL from the drop down list in the Search section under "Set which search engine is used when searching from the omnibox"





In Chrome's omnibox and when Apropos is set as the search engine used on the location bar, you can differentiate domain names you want to lookup from domain names you want to visit by prepending !d to your query eg: http://ipduh.com/apropos/?!d bing.no. If you want to decode and analyze a URI instead of visiting it you can prepend !u to your query, and jump to a Torrent Search by prepending !t to your query.


To add IPduh Apropos over HTTPS to your Internet Explorer Search Engines:


  • visit the IPduh privacy page.

  • click on the down arrow used to select search engine

  • click on Add Search Providers.

  • click on IPduh Apropos SSL.







To add IPduh Apropos over HTTPS to your Opera Search Engines:


  • visit the IPduh privacy page.

  • click on the down arrow used to select search engine

  • click on Manage Search Engines.

  • click the Add... Button.

  • set the Name -- Apropos.

  • set the Keyword -- a.

  • set the address to https://ipduh.com/apropos/?%s

  • The check boxes following are optional.

  • Hit OK








Torrent Search    Tools Menu

Search Torrents across all the major Torrent Trackers, Torrent Directories, and Torrent Search Engines.



Add the Torrent Search to your Browser Search Engines.



Add Torrent Search to Mozilla Firefox and Mozilla based browsers

Add Torrent Search to Internet Explorer

Add Torrent Search to Opera





To add Torrent Search to your Firefox Search Engines:



Add the Firefox Torrent add-on from https://addons.mozilla.org/en-US/firefox/addon/torrent/



OR


  • visit the Torrent Search

  • click on the down arrow used to select search engine

  • click on Add Torrent Search.






To add Torrent Search to your Internet Explorer Search Engines:


  • visit the Torrent Search

  • click on the down arrow used to select search engine

  • click on Add Search Providers.

  • click on Torrent Search.






To add Torrent Search to your Opera Search Engines:


  • visit the Torrent Search


  • click on the down arrow used to select search engine

  • click on Manage Search Engines.

  • click the Add... Button.

  • set the Name -- Torrent Search.

  • set the Keyword -- t.

  • set the address to http://ipduh.com/search/torrent/?q=%s

  • The check boxes following are optional.

  • Hit OK







The Torrent Search is available through apropos with the !t guide.


Add the Torrent Search over HTTPS --an encrypted Connection-- to your Browser Search Engines.



Add Torrent Search over HTTPS to Mozilla Firefox and Mozilla based browsers

Add Torrent Search over HTTPS to Internet Explorer

Add Torrent Search over HTTPS to Opera





To add Torrent Search over HTTPS to your Mozilla Firefox Search Engines:



Add the Firefox Torrent SSL add-on.



OR


  • visit IPduh Privacy

  • click on the down arrow used to select search engine

  • click on Add Torrent Search SSL.






To add Torrent Search over HTTPS to your Internet Explorer Search Engines:


  • visit the IPduh privacy page.

  • click on the down arrow used to select search engine

  • click on Add Search Providers.

  • click on Torrent Search SSL.






To add Torrent Search SSL to your Opera Search Engines:


  • visit the IPduh privacy page.


  • click on the down arrow used to select search engine

  • click on Manage Search Engines.

  • click the Add... Button.

  • set the Name -- Torrent Search SSL.

  • set the Keyword -- t or whatever else you think appropriate.

  • set the address to https://ipduh.com/search/torrent/?q=%s

  • The check boxes following are optional.

  • Hit OK








gmap    Tools Menu

Display a set of coordinates ( latitude , longitude ) on a google map.




input:



Decimal latitude φ, longitude λ in the uri parameters



output:

A google map with a marker on the set of coordinates passed.


Examples of using gmap.






gmap/tolatlon    Tools Menu

Display and Find coordinates ( latitude , longitude ) on a google map.






input:



Markers with Right Click and decimal latitude and longitude in the uri parameters



output:

A google map with a marker on the set of coordinates passed.

You may right click on the map to enter markers and get the coordinates of points.


Examples of using gmap/tolatlon.

















ip  ip/whois  ip/dnsbl  ip/cidr  ip/ptr  ip/ptr/24  ip/dnstrace  ip/srv  ip/traceroute  ip/tor-exit  ip/list

 ip/whois/as  pdb/as  as/prefix  apropos  demux  demux/class  demux/list

 ipv6  ipv6/whois  ipv6/ptr  ipv6/dnstrace  ipv6/cidr  ipv6/traceroute

dns  dns/whois  dns/trace  dns/bl  dns/list  idn  idn/ace  idn/unicode

 anonymity check  url/decode  url/encode  url/bouncer  my/geoloc  epoch

© 1372644985 IPduh Search Contact Privacy








at Tidak ada komentar:
Labels: , , , , , , , , ,

IP Version 6 Addressing Architecture 


Network Working Group                                          R. Hinden
Request for Comments: 4291                                         Nokia
Obsoletes: 3513                                               S. Deering
Category: Standards Track                                  Cisco Systems
                                                           February 2006


                  IP Version 6 Addressing Architecture

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification defines the addressing architecture of the IP
   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
   model, text representations of IPv6 addresses, definition of IPv6
   unicast addresses, anycast addresses, and multicast addresses, and an
   IPv6 node's required addresses.

   This document obsoletes RFC 3513, "IP Version 6 Addressing
   Architecture".




















Hinden                      Standards Track                     [Page 1]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


Table of Contents

   1. Introduction ....................................................2
   2. IPv6 Addressing .................................................2
      2.1. Addressing Model ...........................................3
      2.2. Text Representation of Addresses ...........................4
      2.3. Text Representation of Address Prefixes ....................5
      2.4. Address Type Identification ................................6
      2.5. Unicast Addresses ..........................................6
           2.5.1. Interface Identifiers ...............................7
           2.5.2. The Unspecified Address .............................9
           2.5.3. The Loopback Address ................................9
           2.5.4. Global Unicast Addresses ............................9
           2.5.5. IPv6 Addresses with Embedded IPv4 Addresses ........10
           2.5.6. Link-Local IPv6 Unicast Addresses ..................11
           2.5.7. Site-Local IPv6 Unicast Addresses ..................11
      2.6. Anycast Addresses .........................................12
           2.6.1. Required Anycast Address ...........................12
      2.7. Multicast Addresses .......................................13
           2.7.1. Pre-Defined Multicast Addresses ....................15
      2.8. A Node's Required Addresses ...............................17
   3. Security Considerations ........................................18
   4. IANA Considerations ............................................18
   5. Acknowledgements ...............................................18
   6. References .....................................................18
      6.1. Normative References ......................................18
      6.2. Informative References ....................................18
   Appendix A: Creating Modified EUI-64 Format Interface Identifiers .20
   Appendix B: Changes from RFC 3513 .................................22

1.  Introduction

   This specification defines the addressing architecture of the IP
   Version 6 protocol.  It includes the basic formats for the various
   types of IPv6 addresses (unicast, anycast, and multicast).

2.  IPv6 Addressing

   IPv6 addresses are 128-bit identifiers for interfaces and sets of
   interfaces (where "interface" is as defined in Section 2 of [IPV6]).
   There are three types of addresses:

    Unicast:   An identifier for a single interface.  A packet sent to a
               unicast address is delivered to the interface identified
               by that address.






Hinden                      Standards Track                     [Page 2]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


    Anycast:   An identifier for a set of interfaces (typically
               belonging to different nodes).  A packet sent to an
               anycast address is delivered to one of the interfaces
               identified by that address (the "nearest" one, according
               to the routing protocols' measure of distance).

    Multicast: An identifier for a set of interfaces (typically
               belonging to different nodes).  A packet sent to a
               multicast address is delivered to all interfaces
               identified by that address.

   There are no broadcast addresses in IPv6, their function being
   superseded by multicast addresses.

   In this document, fields in addresses are given a specific name, for
   example, "subnet".  When this name is used with the term "ID" for
   identifier after the name (e.g., "subnet ID"), it refers to the
   contents of the named field.  When it is used with the term "prefix"
   (e.g., "subnet prefix"), it refers to all of the address from the
   left up to and including this field.

   In IPv6, all zeros and all ones are legal values for any field,
   unless specifically excluded.  Specifically, prefixes may contain, or
   end with, zero-valued fields.

2.1.  Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

   All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses).  A
   single interface may also have multiple IPv6 addresses of any type
   (unicast, anycast, and multicast) or scope.  Unicast addresses with a
   scope greater than link-scope are not needed for interfaces that are
   not used as the origin or destination of any IPv6 packets to or from
   non-neighbors.  This is sometimes convenient for point-to-point
   interfaces.  There is one exception to this addressing model:

      A unicast address or a set of unicast addresses may be assigned to
      multiple physical interfaces if the implementation treats the
      multiple physical interfaces as one interface when presenting it
      to the internet layer.  This is useful for load-sharing over
      multiple physical interfaces.





Hinden                      Standards Track                     [Page 3]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

2.2.  Text Representation of Addresses

   There are three conventional forms for representing IPv6 addresses as
   text strings:

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
      four hexadecimal digits of the eight 16-bit pieces of the address.
      Examples:

         ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

         2001:DB8:0:0:8:800:200C:417A

      Note that it is not necessary to write the leading zeros in an
      individual field, but there must be at least one numeral in every
      field (except for the case described in 2.).

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.

      For example, the following addresses

         2001:DB8:0:0:8:800:200C:417A   a unicast address
         FF01:0:0:0:0:0:0:101           a multicast address
         0:0:0:0:0:0:0:1                the loopback address
         0:0:0:0:0:0:0:0                the unspecified address

      may be represented as

         2001:DB8::8:800:200C:417A      a unicast address
         FF01::101                      a multicast address
         ::1                            the loopback address
         ::                             the unspecified address

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are




Hinden                      Standards Track                     [Page 4]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:

         0:0:0:0:0:0:13.1.68.3

         0:0:0:0:0:FFFF:129.144.52.38

      or in compressed form:

         ::13.1.68.3

         ::FFFF:129.144.52.38

2.3.  Text Representation of Address Prefixes

   The text representation of IPv6 address prefixes is similar to the
   way IPv4 address prefixes are written in Classless Inter-Domain
   Routing (CIDR) notation [CIDR].  An IPv6 address prefix is
   represented by the notation:

      ipv6-address/prefix-length

   where

      ipv6-address    is an IPv6 address in any of the notations listed
                      in Section 2.2.

      prefix-length   is a decimal value specifying how many of the
                      leftmost contiguous bits of the address comprise
                      the prefix.

   For example, the following are legal representations of the 60-bit
   prefix 20010DB80000CD3 (hexadecimal):

      2001:0DB8:0000:CD30:0000:0000:0000:0000/60
      2001:0DB8::CD30:0:0:0:0/60
      2001:0DB8:0:CD30::/60

   The following are NOT legal representations of the above prefix:

      2001:0DB8:0:CD3/60   may drop leading zeros, but not trailing
                           zeros, within any 16-bit chunk of the address

      2001:0DB8::CD30/60   address to left of "/" expands to
                           2001:0DB8:0000:0000:0000:0000:0000:CD30

      2001:0DB8::CD3/60    address to left of "/" expands to
                           2001:0DB8:0000:0000:0000:0000:0000:0CD3



Hinden                      Standards Track                     [Page 5]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   When writing both a node address and a prefix of that node address
   (e.g., the node's subnet prefix), the two can be combined as follows:

      the node address      2001:0DB8:0:CD30:123:4567:89AB:CDEF
      and its subnet number 2001:0DB8:0:CD30::/60

      can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60

2.4.  Address Type Identification

   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             FF00::/8        2.7
      Link-Local unicast   1111111010           FE80::/10       2.5.6
      Global Unicast       (everything else)

   Anycast addresses are taken from the unicast address spaces (of any
   scope) and are not syntactically distinguishable from unicast
   addresses.

   The general format of Global Unicast addresses is described in
   Section 2.5.4.  Some special-purpose subtypes of Global Unicast
   addresses that contain embedded IPv4 addresses (for the purposes of
   IPv4-IPv6 interoperation) are described in Section 2.5.5.

   Future specifications may redefine one or more sub-ranges of the
   Global Unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as Global Unicast addresses.

2.5.  Unicast Addresses

   IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing.

   There are several types of unicast addresses in IPv6, in particular,
   Global Unicast, site-local unicast (deprecated, see Section 2.5.7),
   and Link-Local unicast.  There are also some special-purpose subtypes
   of Global Unicast, such as IPv6 addresses with embedded IPv4
   addresses.  Additional address types or subtypes can be defined in
   the future.




Hinden                      Standards Track                     [Page 6]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   IPv6 nodes may have considerable or little knowledge of the internal
   structure of the IPv6 address, depending on the role the node plays
   (for instance, host versus router).  At a minimum, a node may
   consider that unicast addresses (including its own) have no internal
   structure:

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

   Though a very simple router may have no knowledge of the internal
   structure of IPv6 unicast addresses, routers will more generally have
   knowledge of one or more of the hierarchical boundaries for the
   operation of routing protocols.  The known boundaries will differ
   from router to router, depending on what positions the router holds
   in the routing hierarchy.

   Except for the knowledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

2.5.1.  Interface Identifiers

   Interface identifiers in IPv6 unicast addresses are used to identify
   interfaces on a link.  They are required to be unique within a subnet
   prefix.  It is recommended that the same interface identifier not be
   assigned to different nodes on a link.  They may also be unique over
   a broader scope.  In some cases, an interface's identifier will be
   derived directly from that interface's link-layer address.  The same
   interface identifier may be used on multiple interfaces on a single
   node, as long as they are attached to different subnets.

   Note that the uniqueness of interface identifiers is independent of
   the uniqueness of IPv6 addresses.  For example, a Global Unicast
   address may be created with a local scope interface identifier and a
   Link-Local address may be created with a universal scope interface
   identifier.



Hinden                      Standards Track                     [Page 7]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

   Modified EUI-64 format-based interface identifiers may have universal
   scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
   or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
   global token is not available (e.g., serial links, tunnel end-points)
   or where global tokens are undesirable (e.g., temporary tokens for
   privacy [PRIV]).

   Modified EUI-64 format interface identifiers are formed by inverting
   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
   forming the interface identifier from IEEE EUI-64 identifiers.  In
   the resulting Modified EUI-64 format, the "u" bit is set to one (1)
   to indicate universal scope, and it is set to zero (0) to indicate
   local scope.  The first three octets in binary of an IEEE EUI-64
   identifier are as follows:

          0       0 0       1 1       2
         |0       7 8       5 6       3|
         +----+----+----+----+----+----+
         |cccc|ccug|cccc|cccc|cccc|cccc|
         +----+----+----+----+----+----+

   written in Internet standard bit-order, where "u" is the
   universal/local bit, "g" is the individual/group bit, and "c" is the
   bits of the company_id.  Appendix A, "Creating Modified EUI-64 Format
   Interface Identifiers", provides examples on the creation of Modified
   EUI-64 format-based interface identifiers.

   The motivation for inverting the "u" bit when forming an interface
   identifier is to make it easy for system administrators to hand
   configure non-global identifiers when hardware tokens are not
   available.  This is expected to be the case for serial links and
   tunnel end-points, for example.  The alternative would have been for
   these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the
   much simpler 0:0:0:1, 0:0:0:2, etc.

   IPv6 nodes are not required to validate that interface identifiers
   created with modified EUI-64 tokens with the "u" bit set to universal
   are unique.

   The use of the universal/local bit in the Modified EUI-64 format
   identifier is to allow development of future technology that can take
   advantage of interface identifiers with universal scope.





Hinden                      Standards Track                     [Page 8]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   The details of forming interface identifiers are defined in the
   appropriate "IPv6 over " specification, such as "IPv6 over
   Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].

2.5.2.  The Unspecified Address

   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
   must never be assigned to any node.  It indicates the absence of an
   address.  One example of its use is in the Source Address field of
   any IPv6 packets sent by an initializing host before it has learned
   its own address.

   The unspecified address must not be used as the destination address
   of IPv6 packets or in IPv6 Routing headers.  An IPv6 packet with a
   source address of unspecified must never be forwarded by an IPv6
   router.

2.5.3.  The Loopback Address

   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
   It may be used by a node to send an IPv6 packet to itself.  It must
   not be assigned to any physical interface.  It is treated as having
   Link-Local scope, and may be thought of as the Link-Local unicast
   address of a virtual interface (typically called the "loopback
   interface") to an imaginary link that goes nowhere.

   The loopback address must not be used as the source address in IPv6
   packets that are sent outside of a single node.  An IPv6 packet with
   a destination address of loopback must never be sent outside of a
   single node and must never be forwarded by an IPv6 router.  A packet
   received on an interface with a destination address of loopback must
   be dropped.

2.5.4.  Global Unicast Addresses

   The general format for IPv6 Global Unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

   where the global routing prefix is a (typically hierarchically-
   structured) value assigned to a site (a cluster of subnets/links),
   the subnet ID is an identifier of a link within the site, and the
   interface ID is as defined in Section 2.5.1.





Hinden                      Standards Track                     [Page 9]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

   Examples of Global Unicast addresses that start with binary 000 are
   the IPv6 address with embedded IPv4 addresses described in Section
   2.5.5.  An example of global addresses starting with a binary value
   other than 000 (and therefore having a 64-bit interface ID field) can
   be found in [GLOBAL].

2.5.5.  IPv6 Addresses with Embedded IPv4 Addresses

   Two types of IPv6 addresses are defined that carry an IPv4 address in
   the low-order 32 bits of the address.  These are the "IPv4-Compatible
   IPv6 address" and the "IPv4-mapped IPv6 address".

2.5.5.1.  IPv4-Compatible IPv6 Address

   The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
   transition.  The format of the "IPv4-Compatible IPv6 address" is as
   follows:

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|    IPv4 address     |
   +--------------------------------------+----+---------------------+

   Note: The IPv4 address used in the "IPv4-Compatible IPv6 address"
   must be a globally-unique IPv4 unicast address.

   The "IPv4-Compatible IPv6 address" is now deprecated because the
   current IPv6 transition mechanisms no longer use these addresses.
   New or updated implementations are not required to support this
   address type.

2.5.5.2.  IPv4-Mapped IPv6 Address

   A second type of IPv6 address that holds an embedded IPv4 address is
   defined.  This address type is used to represent the addresses of
   IPv4 nodes as IPv6 addresses.  The format of the "IPv4-mapped IPv6
   address" is as follows:








Hinden                      Standards Track                    [Page 10]
 
RFC 4291              IPv6 Addressing Architecture         February 2006



   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

   See [RFC4038] for background on the usage of the "IPv4-mapped IPv6
   address".

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

2.5.7.  Site-Local IPv6 Unicast Addresses

   Site-Local addresses were originally designed to be used for
   addressing inside of a site without the need for a global prefix.
   Site-local addresses are now deprecated as defined in [SLDEP].

   Site-Local addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

   The special behavior of this prefix defined in [RFC3513] must no
   longer be supported in new implementations (i.e., new implementations
   must treat this prefix as Global Unicast).

   Existing implementations and deployments may continue to use this
   prefix.




Hinden                      Standards Track                    [Page 11]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


2.6.  Anycast Addresses

   An IPv6 anycast address is an address that is assigned to more than
   one interface (typically belonging to different nodes), with the
   property that a packet sent to an anycast address is routed to the
   "nearest" interface having that address, according to the routing
   protocols' measure of distance.

   Anycast addresses are allocated from the unicast address space, using
   any of the defined unicast address formats.  Thus, anycast addresses
   are syntactically indistinguishable from unicast addresses.  When a
   unicast address is assigned to more than one interface, thus turning
   it into an anycast address, the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address.

   For any assigned anycast address, there is a longest prefix P of that
   address that identifies the topological region in which all
   interfaces belonging to that anycast address reside.  Within the
   region identified by P, the anycast address must be maintained as a
   separate entry in the routing system (commonly referred to as a "host
   route"); outside the region identified by P, the anycast address may
   be aggregated into the routing entry for prefix P.

   Note that in the worst case, the prefix P of an anycast set may be
   the null prefix, i.e., the members of the set may have no topological
   locality.  In that case, the anycast address must be maintained as a
   separate routing entry throughout the entire Internet, which presents
   a severe scaling limit on how many such "global" anycast sets may be
   supported.  Therefore, it is expected that support for global anycast
   sets may be unavailable or very restricted.

   One expected use of anycast addresses is to identify the set of
   routers belonging to an organization providing Internet service.
   Such addresses could be used as intermediate addresses in an IPv6
   Routing header, to cause a packet to be delivered via a particular
   service provider or sequence of service providers.

   Some other possible uses are to identify the set of routers attached
   to a particular subnet, or the set of routers providing entry into a
   particular routing domain.

2.6.1.  Required Anycast Address

   The Subnet-Router anycast address is predefined.  Its format is as
   follows:





Hinden                      Standards Track                    [Page 12]
 
RFC 4291              IPv6 Addressing Architecture         February 2006



   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | 00000000000000 |
   +------------------------------------------------+----------------+

   The "subnet prefix" in an anycast address is the prefix that
   identifies a specific link.  This anycast address is syntactically
   the same as a unicast address for an interface on the link with the
   interface identifier set to zero.

   Packets sent to the Subnet-Router anycast address will be delivered
   to one router on the subnet.  All routers are required to support the
   Subnet-Router anycast addresses for the subnets to which they have
   interfaces.

   The Subnet-Router anycast address is intended to be used for
   applications where a node needs to communicate with any one of the
   set of routers.

2.7.  Multicast Addresses

   An IPv6 multicast address is an identifier for a group of interfaces
   (typically on different nodes).  An interface may belong to any
   number of multicast groups.  Multicast addresses have the following
   format:

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

      binary 11111111 at the start of the address identifies the address
      as being a multicast address.

                                    +-+-+-+-+
      flgs is a set of 4 flags:     |0|R|P|T|
                                    +-+-+-+-+

         The high-order flag is reserved, and must be initialized to 0.

         T = 0 indicates a permanently-assigned ("well-known") multicast
         address, assigned by the Internet Assigned Numbers Authority
         (IANA).

         T = 1 indicates a non-permanently-assigned ("transient" or
         "dynamically" assigned) multicast address.




Hinden                      Standards Track                    [Page 13]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


         The P flag's definition and usage can be found in [RFC3306].

         The R flag's definition and usage can be found in [RFC3956].

      scop is a 4-bit multicast scope value used to limit the scope of
      the multicast group.  The values are as follows:

         0  reserved
         1  Interface-Local scope
         2  Link-Local scope
         3  reserved
         4  Admin-Local scope
         5  Site-Local scope
         6  (unassigned)
         7  (unassigned)
         8  Organization-Local scope
         9  (unassigned)
         A  (unassigned)
         B  (unassigned)
         C  (unassigned)
         D  (unassigned)
         E  Global scope
         F  reserved

         Interface-Local scope spans only a single interface on a node
         and is useful only for loopback transmission of multicast.

         Link-Local multicast scope spans the same topological region as
         the corresponding unicast scope.

         Admin-Local scope is the smallest scope that must be
         administratively configured, i.e., not automatically derived
         from physical connectivity or other, non-multicast-related
         configuration.

         Site-Local scope is intended to span a single site.

         Organization-Local scope is intended to span multiple sites
         belonging to a single organization.

         scopes labeled "(unassigned)" are available for administrators
         to define additional multicast regions.

      group ID identifies the multicast group, either permanent or
      transient, within the given scope.  Additional definitions of the
      multicast group ID field structure are provided in [RFC3306].





Hinden                      Standards Track                    [Page 14]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   The "meaning" of a permanently-assigned multicast address is
   independent of the scope value.  For example, if the "NTP servers
   group" is assigned a permanent multicast address with a group ID of
   101 (hex), then

      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
      (i.e., the same node) as the sender.

      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
      sender.

      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
      sender.

      FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.

   Non-permanently-assigned multicast addresses are meaningful only
   within a given scope.  For example, a group identified by the non-
   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
   site bears no relationship to a group using the same address at a
   different site, nor to a non-permanent group using the same group ID
   with a different scope, nor to a permanent group with the same group
   ID.

   Multicast addresses must not be used as source addresses in IPv6
   packets or appear in any Routing header.

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; if
   such a packet is sent or received, it must be treated the same as
   packets destined to a global (scop E) multicast address.

2.7.1.  Pre-Defined Multicast Addresses

   The following well-known multicast addresses are pre-defined.  The
   group IDs defined in this section are defined for explicit scope
   values.

   Use of these group IDs for any other scope values, with the T flag
   equal to 0, is not allowed.






Hinden                      Standards Track                    [Page 15]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
                                      FF01:0:0:0:0:0:0:0
                                      FF02:0:0:0:0:0:0:0
                                      FF03:0:0:0:0:0:0:0
                                      FF04:0:0:0:0:0:0:0
                                      FF05:0:0:0:0:0:0:0
                                      FF06:0:0:0:0:0:0:0
                                      FF07:0:0:0:0:0:0:0
                                      FF08:0:0:0:0:0:0:0
                                      FF09:0:0:0:0:0:0:0
                                      FF0A:0:0:0:0:0:0:0
                                      FF0B:0:0:0:0:0:0:0
                                      FF0C:0:0:0:0:0:0:0
                                      FF0D:0:0:0:0:0:0:0
                                      FF0E:0:0:0:0:0:0:0
                                      FF0F:0:0:0:0:0:0:0

   The above multicast addresses are reserved and shall never be
   assigned to any multicast group.

      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
                              FF02:0:0:0:0:0:0:1

   The above multicast addresses identify the group of all IPv6 nodes,
   within scope 1 (interface-local) or 2 (link-local).

      All Routers Addresses:   FF01:0:0:0:0:0:0:2
                               FF02:0:0:0:0:0:0:2
                               FF05:0:0:0:0:0:0:2

   The above multicast addresses identify the group of all IPv6 routers,
   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).

      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX

   Solicited-Node multicast address are computed as a function of a
   node's unicast and anycast addresses.  A Solicited-Node multicast
   address is formed by taking the low-order 24 bits of an address
   (unicast or anycast) and appending those bits to the prefix
   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
   range

         FF02:0:0:0:0:1:FF00:0000

   to

         FF02:0:0:0:0:1:FFFF:FFFF




Hinden                      Standards Track                    [Page 16]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   For example, the Solicited-Node multicast address corresponding to
   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
   addresses that differ only in the high-order bits (e.g., due to
   multiple high-order prefixes associated with different aggregations)
   will map to the same Solicited-Node address, thereby reducing the
   number of multicast addresses a node must join.

   A node is required to compute and join (on the appropriate interface)
   the associated Solicited-Node multicast addresses for all unicast and
   anycast addresses that have been configured for the node's interfaces
   (manually or automatically).

2.8.  A Node's Required Addresses

   A host is required to recognize the following addresses as
   identifying itself:

      o Its required Link-Local address for each interface.

      o Any additional Unicast and Anycast addresses that have been
        configured for the node's interfaces (manually or
        automatically).

      o The loopback address.

      o The All-Nodes multicast addresses defined in Section 2.7.1.

      o The Solicited-Node multicast address for each of its unicast and
        anycast addresses.

      o Multicast addresses of all other groups to which the node
        belongs.

   A router is required to recognize all addresses that a host is
   required to recognize, plus the following addresses as identifying
   itself:

      o The Subnet-Router Anycast addresses for all interfaces for which
        it is configured to act as a router.

      o All other Anycast addresses with which the router has been
        configured.

      o The All-Routers multicast addresses defined in Section 2.7.1.







Hinden                      Standards Track                    [Page 17]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


3.  Security Considerations

   IPv6 addressing documents do not have any direct impact on Internet
   infrastructure security.  Authentication of IPv6 packets is defined
   in [AUTH].

4.  IANA Considerations

   The "IPv4-Compatible IPv6 address" is deprecated by this document.
   The IANA should continue to list the address block containing these
   addresses at http://www.iana.org/assignments/ipv6-address-space as
   "Reserved by IETF" and not reassign it for any other purpose.  For
   example:

      0000::/8        Reserved by IETF        [RFC3513]      [1]

   The IANA has added the following note and link to this address block.

      [5]  0000::/96 was previously defined as the "IPv4-Compatible IPv6
           address" prefix.  This definition has been deprecated by RFC
           4291.

   The IANA has updated the references for the IPv6 Address Architecture
   in the IANA registries accordingly.

5.  Acknowledgements

   The authors would like to acknowledge the contributions of Paul
   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
   Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino,
   Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali.

6.  References

6.1.  Normative References

   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

6.2.  Informative References

   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.





Hinden                      Standards Track                    [Page 18]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
             Inter-Domain Routing (CIDR): an Address Assignment and
             Aggregation Strategy", RFC 1519, September 1993.

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", RFC 2464, December 1998.

   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority",
             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
             March 1997.

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", RFC 2467, December 1998.

   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
             Unicast Address Format", RFC 3587, August 2003.

   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
             Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 3513, April 2005.

   [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
             Multicast Addresses", RFC 3306, August 2002.

   [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
             (RP) Address in an IPv6 Multicast Address", RFC 3956,
             November 2004.

   [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
             Castro, "Application Aspects of IPv6 Transition", RFC 4038,
             March 2005.

   [SLDEP]   Huitema, C. and B. Carpenter, "Deprecating Site Local
             Addresses", RFC 3879, September 2004.














Hinden                      Standards Track                    [Page 19]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


Appendix A: Creating Modified EUI-64 Format Interface Identifiers

   Depending on the characteristics of a specific link or node, there
   are a number of approaches for creating Modified EUI-64 format
   interface identifiers. This appendix describes some of these
   approaches.

   Links or Nodes with IEEE EUI-64 Identifiers

   The only change needed to transform an IEEE EUI-64 identifier to an
   interface identifier is to invert the "u" (universal/local) bit.  An
   example is a globally unique IEEE EUI-64 identifier of the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   where "c" is the bits of the assigned company_id, "0" is the value of
   the universal/local bit to indicate universal scope, "g" is
   individual/group bit, and "m" is the bits of the manufacturer-
   selected extension identifier.  The IPv6 interface identifier would
   be of the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   The only change is inverting the value of the universal/local bit.

   Links or Nodes with IEEE 802 48-bit MACs

   [EUI64] defines a method to create an IEEE EUI-64 identifier from an
   IEEE 48-bit MAC identifier.  This is to insert two octets, with
   hexadecimal values of 0xFF and 0xFE (see the Note at the end of
   appendix), in the middle of the 48-bit MAC (between the company_id
   and vendor-supplied id).  An example is the 48-bit IEEE MAC with
   Global scope:

   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+




Hinden                      Standards Track                    [Page 20]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   where "c" is the bits of the assigned company_id, "0" is the value of
   the universal/local bit to indicate Global scope, "g" is
   individual/group bit, and "m" is the bits of the manufacturer-
   selected extension identifier.  The interface identifier would be of
   the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   When IEEE 802 48-bit MAC addresses are available (on an interface or
   a node), an implementation may use them to create interface
   identifiers due to their availability and uniqueness properties.

   Links with Other Kinds of Identifiers

   There are a number of types of links that have link-layer interface
   identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs.  Examples
   include LocalTalk and Arcnet.  The method to create a Modified EUI-64
   format identifier is to take the link identifier (e.g., the LocalTalk
   8-bit node identifier) and zero fill it to the left.  For example, a
   LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in
   the following interface identifier:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

   Note that this results in the universal/local bit set to "0" to
   indicate local scope.

   Links without Identifiers

   There are a number of links that do not have any type of built-in
   identifier.  The most common of these are serial links and configured
   tunnels.  Interface identifiers that are unique within a subnet
   prefix must be chosen.

   When no built-in identifier is available on a link, the preferred
   approach is to use a universal interface identifier from another
   interface or one that is assigned to the node itself.  When using
   this approach, no other interface connecting the same node to the
   same subnet prefix may use the same identifier.




Hinden                      Standards Track                    [Page 21]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


   If there is no universal interface identifier available for use on
   the link, the implementation needs to create a local-scope interface
   identifier.  The only requirement is that it be unique within a
   subnet prefix.  There are many possible approaches to select a
   subnet-prefix-unique interface identifier.  These include the
   following:

      Manual Configuration
      Node Serial Number
      Other Node-Specific Token

   The subnet-prefix-unique interface identifier should be generated in
   a manner such that it does not change after a reboot of a node or if
   interfaces are added or deleted from the node.

   The selection of the appropriate algorithm is link and implementation
   dependent.  The details on forming interface identifiers are defined
   in the appropriate "IPv6 over " specification.  It is strongly
   recommended that a collision detection algorithm be implemented as
   part of any automatic algorithm.

   Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
         inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
         48 identifier.  The 0xFF and 0xFE values are used when starting
         with an IEEE EUI-48 identifier.  The incorrect value was used
         in earlier versions of the specification due to a
         misunderstanding about the differences between IEEE MAC-48 and
         EUI-48 identifiers.

         This document purposely continues the use of 0xFF and 0xFE
         because it meets the requirements for IPv6 interface
         identifiers (i.e., that they must be unique on the link), IEEE
         EUI-48 and MAC-48 identifiers are syntactically equivalent, and
         that it doesn't cause any problems in practice.

Appendix B: Changes from RFC 3513

   The following changes were made from RFC 3513, "IP Version 6
   Addressing Architecture":

    o The restrictions on using IPv6 anycast addresses were removed
      because there is now sufficient experience with the use of anycast
      addresses, the issues are not specific to IPv6, and the GROW
      working group is working in this area.

    o Deprecated the Site-Local unicast prefix.  Changes include the
      following:




Hinden                      Standards Track                    [Page 22]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


       - Removed Site-Local from special list of prefixes in Section
         2.4.

       - Split section titled "Local-use IPv6 Unicast Addresses" into
         two sections, "Link-Local IPv6 Unicast Addresses" and "Site-
         Local IPv6 Unicast Addresses".

       - Added text to new section describing Site-Local deprecation.

    o Changes to resolve issues raised in IAB response to Robert Elz
      appeal.  Changes include the following:

       - Added clarification to Section 2.5 that nodes should make no
         assumptions about the structure of an IPv6 address.

       - Changed the text in Section 2.5.1 and Appendix A to refer to
         the Modified EUI-64 format interface identifiers with the "u"
         bit set to one (1) as universal.

       - Added clarification to Section 2.5.1 that IPv6 nodes are not
         required to validate that interface identifiers created in
         Modified EUI-64 format with the "u" bit set to one are unique.

    o Changed the reference indicated in Section 2.5.4 "Global Unicast
      Addresses" to RFC 3587.

    o Removed mention of NSAP addresses in examples.

    o Clarified that the "x" in the textual representation can be one to
      four digits.

    o Deprecated the "IPv6 Compatible Address" because it is not being
      used in the IPv6 transition mechanisms.

    o Added the "R" and "P" flags to Section 2.7 on multicast addresses,
      and pointers to the documents that define them.

    o Editorial changes.













Hinden                      Standards Track                    [Page 23]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


Authors' Addresses

   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: +1 650 625-2004
   EMail: bob.hinden@nokia.com


   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA


































Hinden                      Standards Track                    [Page 24]
 
RFC 4291              IPv6 Addressing Architecture         February 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Hinden                      Standards Track                    [Page 25]




at Tidak ada komentar:
Labels: , , , , , , ,
Langganan: Postingan (Atom)

Demokrasi Pancasila Berdasarkan Agama dan Relevansinya terhadap Perilaku Sosial

  Demokrasi Pancasila Berdasarkan Agama dan Relevansinya terhadap Perilaku Sosial   BAB I PENDAHULUAN   Demokrasi Pancasila bukan...